Toon posts:

[SQL] 1-op-1 relatie tabellen bij kolom met veel data

Pagina: 1
Acties:

Onderwerpen


  • Jan_V
  • Registratie: maart 2002
  • Laatst online: 16:08
Gisteren was ik op de SQL Zaterdag en hoorde een van de sprekers iets zeggen waar ik nog nooit over had nagedacht. Namelijk dat het in sommige situaties misschien handig kan zijn om kolommen met veel data (varchar(8000), varchar(max), varbinary, etc) op te slaan in een andere tabel welke een 1:1 relatie heeft met de originele tabel.
Dit zou als voordeel bieden dat een table-scan veel sneller uitgevoerd zou kunnen worden, omdat de kolom met veel data dan niet hoeft worden bekeken en er dus meer records in een page kunnen worden geplaatst, wat de performance ten goede zou kunnen komen. Hier zit natuurlijk wat in.

Wanneer ik zelf een database moet ontwerpen plaats ik momenteel vaak de grote kolommen gewoon in dezelfde tabel als de overige velden. Dit hoeft natuurlijk niet, want vaak hoef je de kolommen met veel data alleen te tonen/op te vragen op de detail pagina van een item. In alle overige gevallen ben je vaak alleen geïnteresseerd in de kleinere kolommen welke FK's, id's, etc. bevatten.
Het opslaan van een grote kolom in een andere tabel kost natuurlijk wel iets meer bij het ophalen van de data (extra join noodzakelijk).

Zijn er hier mensen die een dergelijke opzet gebruiken en is dat dan om performance redenen? Het komt de duidelijkheid van je database vaak niet ten goede denk ik.

Battle.net - Jandev#2601 / XBOX: VriesDeJ


  • Janoz
  • Registratie: oktober 2000
  • Laatst online: 16:08

Janoz

Moderator Devschuur®

!litemod

Wanneer je ipv varchar(8000) colomtypes als BLOB, TEXT of CBLOB gebruikt gebeurt dit onder de motorkap al vanzelf.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


  • Jan_V
  • Registratie: maart 2002
  • Laatst online: 16:08
Zoiets dacht ik ook. Wanneer je een varchar(max) (text is depricated voor zover ik weet) gebruikt, dat je dan gewoon een pointer terug krijgt naar de tekst die pas wordt opgehaald wanneer je die nodig hebt.
Vandaar dat ik het ook een aparte stelling vond.

Battle.net - Jandev#2601 / XBOX: VriesDeJ


  • JaQ
  • Registratie: juni 2001
  • Laatst online: 07:06
Janoz schreef op zondag 24 oktober 2010 @ 15:01:
Wanneer je ipv varchar(8000) colomtypes als BLOB, TEXT of CBLOB gebruikt gebeurt dit onder de motorkap al vanzelf.
Je kan een tabel zo modificeren dat de blob (etc) wel in de rij wordt opgeslagen. Je beschrijft enkel het default gedrag van SQL-Server. In andere RDBMS-en kan dit gedrag anders zijn, bijvoorbeeld in Oracle wordt een lob default wel in de rij opgeslagen (en moet je derhalve expliciet aangeven of je de lob ergens anders wilt opslaan).

Misschien was de spreker iemand die gek is op database onafhankelijke programmatuur (of zo) :)

Egoist: A person of low taste, more interested in themselves than in me


  • Wolfboy
  • Registratie: januari 2001
  • Niet online

Wolfboy

ubi dubium ibi libertas

Het verschilt nogal per database type of dit wel/geen effect heeft.

Bij Oracle moet je expliciet opgeven waar je het spul wil opslaan, anders komt het gewoon de tabel terecht.
Bij Postgres heb je TOAST die het sowieso al ergens opslaat (kan je ook opgeven waar het terecht moet komen).
Bij SQL server gaat dit automatisch bij Text types en niet bij varchar kolommen.
Bij MySQL gaat dit afaik hetzelfde als bij SQL server

Dus... afhankelijk van je database server kan dit belangrijk zijn ja ;)

Blog [Stackoverflow] [LinkedIn]


  • GlowMouse
  • Registratie: november 2002
  • Niet online

GlowMouse

wees solidair

Wolfboy schreef op zondag 24 oktober 2010 @ 20:34:
Bij MySQL gaat dit afaik hetzelfde als bij SQL server
Het is sterk afhankelijk van de storage engine, en zelfs binnen storage engines is het erg verschillend, zie hier en hier voor innodb.

Het zal alleen weinig voorkomen dat je full table scans op zulke tabellen uitvoert.

geeft geen inhoudelijke reacties meer


  • 164019
  • Registratie: december 2005
  • Laatst online: 21-07-2014
En doet niet elke database zo'n beetje wat de bedoeling is als je (zoals Janoz aangeeft) een large object datatype (BLOB, CLOB, NCLOB) gebruikt? Waar wil Oracle dat je het aangeeft, bijvoorbeeld? Toch hopelijk niet in het schema zelf?

[Voor 27% gewijzigd door 164019 op 25-10-2010 08:27]


  • Voutloos
  • Registratie: januari 2002
  • Niet online
Jan_V schreef op zondag 24 oktober 2010 @ 14:28:
Dit zou als voordeel bieden dat een table-scan veel sneller uitgevoerd zou kunnen worden...
De echte optimalisatie is natuurlijk het weghalen van de noodzaak voor een tablescan. B)

{signature}


  • Wolfboy
  • Registratie: januari 2001
  • Niet online

Wolfboy

ubi dubium ibi libertas

Voutloos schreef op maandag 25 oktober 2010 @ 08:59:
[...]
De echte optimalisatie is natuurlijk het weghalen van de noodzaak voor een tablescan. B)
Maar... laten we nu even uitgaan van een tabel waar je maar 25 van de 26 velden nodig hebt en dus niet dat veld met die enorme varchar kolom.

Daarnaast is de tabel geclusterd op datum en sorteer je op datum.

In dat geval moet je ook bij een simpele "haal de laatste 1000 rijen op" nog steeds over die varchar kolom heenspringen terwijl je anders alles in 1 sequentiele read zou kunnen lezen.

Blog [Stackoverflow] [LinkedIn]


  • Janoz
  • Registratie: oktober 2000
  • Laatst online: 16:08

Janoz

Moderator Devschuur®

!litemod

Default setting of niet. De storage engine/tabel configuratie is het niveau om dit soort optimalisaties op te pakken, niet door je eigen datamodel te verminken.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


  • 164019
  • Registratie: december 2005
  • Laatst online: 21-07-2014
Nogmaals: gebruik BLOB (BINARY LARGE OBJECT), CLOB (CHARACTER LARGE OBJECT) of NCLOB (NATIONAL CHARACTER LARGE OBJECT) als je al per definitie weet dat het een kolom met "enorme lappen tekst" kan zijn. Waarom? Omdat je model zo in elkaar zit en dit dus het juiste datatype is. Een beetje DBMS moet wel snappen dat 'ie daar voorzichtig mee moet omspringen wanneer performance belangrijk is.

[Voor 12% gewijzigd door 164019 op 25-10-2010 12:54]


  • YopY
  • Registratie: september 2003
  • Laatst online: 09:51
Janoz schreef op maandag 25 oktober 2010 @ 10:51:
Default setting of niet. De storage engine/tabel configuratie is het niveau om dit soort optimalisaties op te pakken, niet door je eigen datamodel te verminken.
+1. Doe gewoon een goed datamodel (op basis van een goeie analyse) en haal alles uit je database op basis van gewone indexes en instellingen, ga dan pas grijpen naar dit soort 'optimalisaties'.

  • tazzman
  • Registratie: juli 2000
  • Laatst online: 06-09 13:50

tazzman

a real boardmonkey

YopY schreef op maandag 25 oktober 2010 @ 12:59:
[...]


+1. Doe gewoon een goed datamodel (op basis van een goeie analyse) en haal alles uit je database op basis van gewone indexes en instellingen, ga dan pas grijpen naar dit soort 'optimalisaties'.
Oneens - je moet de scheiding treffen tussen je concept datamodel, je logische datamodel en je physieke datamodel.

Wanneer je echt grote databases (Enterprise Data Warehousing) ontwerpt op bijvoorbeeld Teradata of HP Neoview dan is het zeker belangrijk om rekening te houden met je physieke model en hoe je bepaalde nodes wel of niet wilt belasten. Ik kom regelmatig bij klanten waar juist geen rekening gehouden is met het physieke model en te veel berust is op het vermogen de interne storage engine van Teradata of Neoview .. met als gevolg dat na 15-20TB de omgeving compleet vastloopt.

Het nieuwe speelgoed: een Saab 9-3 Aero (absoluut, helemaal en compleet fantastisch....)


  • RobIII
  • Registratie: december 2001
  • Laatst online: 14:03

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

tazzman schreef op donderdag 18 november 2010 @ 01:26:
Wanneer je echt grote databases ... met als gevolg dat na 15-20TB de omgeving compleet vastloopt.
Is dit nou een verkapte "kijk mij eens een grote piemel hebben"-post? Komaan; we hebben het hier over "doorsnee" situaties. Over databases in die orde van grootte, noch Teradata / Neoview heeft niemand iets gezegd. Daarbij bevestig je alleen maar YopY's post; als je verwacht dusdanig veel data te gaan verstouwen had je daar eerder bij stil moeten staan (goede analyse).

[Voor 15% gewijzigd door RobIII op 18-11-2010 01:44]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Roses are red Violets are blue, Unexpected ‘{‘ on line 32.

Over mij


  • defcon84
  • Registratie: september 2009
  • Laatst online: 07-09 09:08

defcon84

Multipass?

RobIII schreef op donderdag 18 november 2010 @ 01:42:
"kijk mij eens een grote piemel hebben"
_O-
ja, ik weet het, onnodige reply, maar hier moest ik even voor op de grond slaan :p

Untappd | "Dogs fucked the pope, no fault of mine." -Hunter S. Thompson

Pagina: 1


Nintendo Switch (OLED model) Apple iPhone 13 LG G1 Google Pixel 6 Call of Duty: Vanguard Samsung Galaxy S21 5G Apple iPad Pro (2021) 11" Wi-Fi, 8GB ram Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2021 Hosting door True

Tweakers maakt gebruik van cookies

Bij het bezoeken van het forum plaatst Tweakers alleen functionele en analytische cookies voor optimalisatie en analyse om de website-ervaring te verbeteren. Op het forum worden geen trackingcookies geplaatst. Voor het bekijken van video's en grafieken van derden vragen we je toestemming, we gebruiken daarvoor externe tooling die mogelijk cookies kunnen plaatsen.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Forum cookie-instellingen

Bekijk de onderstaande instellingen en maak je keuze. Meer informatie vind je in ons cookiebeleid.

Functionele en analytische cookies

Deze cookies helpen de website zijn functies uit te voeren en zijn verplicht. Meer details

janee

    Cookies van derden

    Deze cookies kunnen geplaatst worden door derde partijen via ingesloten content en om de gebruikerservaring van de website te verbeteren. Meer details

    janee