[Normalisatie] 1NF tegen SubStr

[Verwijderd]

Vanuit de discussie die ontsproten is in een andere thread leek het me handig een apart topic te maken.

Deze thread gaat over functies als SubString tegen de eerste normaal vorm. Mijn stelling is:
als je SubString() in een willekeurige query nodig hebt is je database niet in de eerste normaal vorm

Ik vind het belangrijk dat een database in 1NF is, omdat dit de integriteit van gegevens ten goede komt.

Graag hoor ik hoe jullie hier over denken.

[Gé Brander]

Het lijkt mij de grootst mogelijk onzin om op deze manier je unieke entiteiten op te gaan delen. Het kan heel valide zijn om ze te behouden.

Stel je nu eens voor dat je de entiteit servernaam die gevuld wordt als machinenaam\instancenaam hebt. Dan zou je volgens jouw logica dus een apart tabelletje moeten hebben met '\' en eventueel een identity kolom, want die '\' komt in elke rij voor.

Lijkt mij dus echt onzin.

Als je echter kijkt naar een ander heel simpel voorbeeld:

Adres: Pietjepuklaan 18
Postcode Woonplaats: 1234 AB Lutjebroek

Dan heb je een punt.

[ Voor 25% gewijzigd door Gé Brander op 30-03-2005 14:27 ]

[Verwijderd]

Compleet mee eens. Wanneer je substring moet gebruiken om een "unieke" id om te zetten in iets anders had je veel beter die twee velden kunnen koppelen en samen uniek maken. Een simpel voorbeeld waarbij je instellingen kunt opslaan in een tabel, en er ook nog groepen bij hebt:

code:

CREATE TABLE instellingen_voorbeeld (
   group varchar(50) not null,
   name varchar(50) not null,
   value varchar(50),
   primary key(group, name)
);

[ Voor 5% gewijzigd door Verwijderd op 30-03-2005 14:30 . Reden: Code tags voor sql stukje :) ]

[twiekert]

Puur de stelling dat als je de functie substring in een query gebruikt dat je database niet genormaliseerd is is gewoon onzin.

Stel je voor dat je een stukje van de tekst in een text veld wil laten zien, bijvoorbeeld de eerste 100 karakters, en de tekst zelf bestaat uit 1000 karakters. Als je dan geen sql functie substring mag gebruiken dan zou je dus alle tekst op moeten halen in de programmeertaal om deze alsnog te substringen ?

of je moet een extra veld aanmaken met de eerste 100 karakters van de tekst kolom, maar dat is geen normalisatie...

[Verwijderd]

Verwijderd schreef op woensdag 30 maart 2005 @ 14:29:
Compleet mee eens. Wanneer je substring moet gebruiken om een "unieke" id om te zetten in iets anders had je veel beter die twee velden kunnen koppelen en samen uniek maken. Een simpel voorbeeld waarbij je instellingen kunt opslaan in een tabel, en er ook nog groepen bij hebt:

code:

CREATE TABLE instellingen_voorbeeld (
   group varchar(50) not null,
   name varchar(50) not null,
   value varchar(50),
   primary key(group, name)
);

Daar gaat het dus helemaal niet om, in het door bloog aangehaalde topic wil iemand een update op een veld doen en heeft een substr() nodig om het juiste effect te bewerkstelligen. Dit hebben ik en anderen in dat andere topic al geprobeerd duidelijk te maken maar volgens mij zitten we nog steeds niet met bloog op één lijn.

[ Voor 3% gewijzigd door Verwijderd op 30-03-2005 14:34 ]

[Verwijderd]

c70070540 schreef op woensdag 30 maart 2005 @ 14:25:
...
Dan zou je volgens jouw logica dus een apart tabelletje moeten hebben met '\' en eventueel een identity kolom, want die '\' komt in elke rij voor.

Dan zou je idd twee tabellen gebruiken, want die machinenaam gaat meerdere keren voorkomen, en als alleen de machinenaam zou veranderen heb je een hoop in je db te wijzigen. Dat die backslash erin hoort te staan heeft niets met je data te maken; een scriptje zou dat er tussen kunnen zetten.

Wil je een overzicht van alle shares per machine, dan heb je helemaal niets aan die backslash. Dat wat jij zegt hangt totaal af van wat je met je gegevens wil. En idd, als je je gegevens structureel opsplitst in verschillende entiteiten hoor je dat in aparte tabellen te zetten.

Van de andere kant, bij marktplaats worden bijv. de eerste vier tekens van de postcode getoond, zodat je ongeveer weet hoe ver het bij je vandaan is. De laatste twee tekens hoef je niet te zien ivm. privacy. Zou je de postcode dan over twee tabellen splitsen? Ik zou het raar vinden.

[Verwijderd]

twiekert schreef op woensdag 30 maart 2005 @ 14:33:
Puur de stelling dat als je de functie substring in een query gebruikt dat je database niet genormaliseerd is is gewoon onzin.

Stel je voor dat je een stukje van de tekst in een text veld wil laten zien, bijvoorbeeld de eerste 100 karakters, en de tekst zelf bestaat uit 1000 karakters. Als je dan geen sql functie substring mag gebruiken dan zou je dus alle tekst op moeten halen in de programmeertaal om deze alsnog te substringen ?

of je moet een extra veld aanmaken met de eerste 100 karakters van de tekst kolom, maar dat is geen normalisatie...

Dit lijkt mij een goed argument tegen. Mijn stelling is onhoudbaar.

[Verwijderd]

Verwijderd schreef op woensdag 30 maart 2005 @ 14:37:
[...]
Van de andere kant, bij marktplaats worden bijv. de eerste vier tekens van de postcode getoond, zodat je ongeveer weet hoe ver het bij je vandaan is. De laatste twee tekens hoef je niet te zien ivm. privacy. Zou je de postcode dan over twee tabellen splitsen? Ik zou het raar vinden.

Postcode niet maar adres, huisnummer, woonplaats vind ik dus wel te splitsen. Het verbergen van de letters van de postcode heeft niks met opslag te maken, maar met weergave. Deze weergave kan door zowel database als verwekende eenheid (php) geregeld worden.

[Verwijderd]

Verwijderd schreef op woensdag 30 maart 2005 @ 14:40:
[...]

Het verbergen van de letters van de postcode heeft niks met opslag te maken, maar met weergave.

als je SubString() in een willekeurige query nodig hebt is je database niet in de eerste normaal vorm

Als ik TS goed begrijp, zou hij het incorrect vinden als je dit op zou lossen door een substring in de select-query te gebruiken. Jij zegt net dat oa. de database hiervoor wel gebruikt kan worden, wat ik met het voorbeeld ook bedoelde. Doordat je de database een substring zou laten selecteren, beweert bloog dat het ontwerp van de database niet juist is. Ik wilde dus duidelijk maken dat voor weergave van gegevens heel goed een substring gebruikt kan worden, net als in het voorbeeld dat je maar een aantal karakters van een stuk tekst wil laten zien.

Ik las die reply alleen te laat.

[Tinoo]

Om nog even op de postcode terug te komen. Volgens mij ligt het er ook maar helemaal aan wat je met de gegevens wil. Voor geografische gegevens zou ik de postcode zeker splitsen aangezien postcodecijfers; postcodeletters en huisnr de geografische plek aangeven. Voor een adressenbestand lijkt het me weer overbodig, meerdere mensen op 1 adres kan voorkomen.

on topic: Substring gebruiken is soms alleen al noodzakelijk om gegevens te kunnen koppelen met gegevens uit andere systemen met een soortgelijke of verkorte sleutel..

[Soultaker]

Misschien is de stelling beter als je stelt dat SubString alleen gebruikt zou moeten worden bij het formatteren van gegevens en niet bij het selecteren ervan? Met andere woorden, SubString mag wel na SELECT maar niet na WHERE voorkomen?

Het opleveren van een deel van een veld zal niemand echt slecht vinden, maar als je SubString gebruikt omdat je anders niet nauwkeurig genoeg kan aanduiden welke result set je wil hebben, is dat waarschijnlijk wel.

Daar staat trouwens tegenover dat als je SubString gebruikt om een prefix te bepalen (dus een substring die begint bij het begin) dan kan een beetje RDBMS met een B-Tree index dat ook efficiënt oplossen. Om de eerste delen van velden te matchen is het dus nog niet zo verkeerd.

[ Voor 54% gewijzigd door Soultaker op 30-03-2005 15:07 ]

[GarBaGe]

Ik heb ff het originele topic gelezen...

Ik vind een substr in een update HEEL verkeerd (1NF enzo, lees argumenten van anderen)....
ECHTER
als het gaat om een EENMALIGE gegevensconversie ivm wijzigen van de database, dan het is wel verrekte handig om een query te typen, ipv een compleet conversie programma typen

[Verwijderd]

Soultaker schreef op woensdag 30 maart 2005 @ 15:04:
[...]
Met andere woorden, SubString mag wel na SELECT maar niet na WHERE voorkomen?

Als het na een WHERE voor zou komen, houdt dat in dat het niet alleen de weergave betreft, maar ook de opslag. Dan zou je het ook op moeten splitsen in twee tabellen. Ik zou het alleen in de SELECT correct vinden. In een UPDATE, zoals dat in het oorspronkelijke topic het geval is, vind ik het fout, tenzij het een eenmalige actie is om gegevens om te zetten naar een ander formaat oid., zoals GarBaGe aangeeft.