[SQL] Deel van een veld vervangen

[GoodspeeD]

Het volgende probleem. We hebben in de database een veld, bestaande uit 20 karakters. Nu wil ik het zevende karakter vervangen door een punt. Is dit mogelijk met basis SQL statements?

We maken geen gebruiker van MS SQL-server, MySQL of een ander SQL-dbms, maar een vrij onbekende filegebaseerde database, waar we een tool voor hebben die SQL-statements accepteert en deze omzet naar eigenlijk simpele filecommando's.

Het is ook niet mogelijk om programmacode te gebruiken in deze tool. Het moet dus echt pure SQL zijn.

[curry684]

Da's compleet afhankelijk van welk dialect SQL je tooltje spreekt. In MS SQL Server zou dit bijvoorbeeld werken:

code:

UPDATE TABLE SET Field = LEFT(Field, 6) + '.' + RIGHT(Field, LEN(Field) - 7);

In andere DBMS'en zijn er weer andere lokale extensies voor. Als het puur in ANSI SQL-92 moet heb je vziw pech

[GoodspeeD]

curry684 schreef op woensdag 30 maart 2005 @ 09:30:
Da's compleet afhankelijk van welk dialect SQL je tooltje spreekt. In MS SQL Server zou dit bijvoorbeeld werken:

code:

UPDATE TABLE SET Field = LEFT(Field, 6) + '.' + RIGHT(Field, LEN(Field) - 7);

In andere DBMS'en zijn er weer andere lokale extensies voor. Als het puur in ANSI SQL-92 moet heb je vziw pech

LEFT en RIGHT had ik al geprobeerd, maar dat werkt dus niet. Conclusie: het moet ANSI SQL-92 zijn.

Bedankt voor je antwoord iig.

[Verwijderd]

Je hebt nog de functie SUBSTRING, maar durf daarover niet te zeggen in hoeverre deze voldoet aan de ANSI SQL-92

[Verwijderd]

als er geen substr of substring achtige functie in zit heb je wel een probleem. Welke build-ins heb je tot je beschikking?

[GoodspeeD]

SUBSTRING en SUBSTR werken. Bedankt voor de hulp.

[Verwijderd]

Databases vinden dit soort operaties a-relaxt. Je gegevens zijn namelijk (zelfs) niet in de eerste normaalvorm. Kijk nog eens naar je databasestructuur.

[curry684]

Verwijderd schreef op woensdag 30 maart 2005 @ 10:35:
Databases vinden dit soort operaties a-relaxt. Je gegevens zijn namelijk (zelfs) niet in de eerste normaalvorm. Kijk nog eens naar je databasestructuur.

Hoe de n**k destilleer je uit de gegeven informatie dat het datamodel fout is?

[GoodspeeD]

Verwijderd schreef op woensdag 30 maart 2005 @ 10:35:
Databases vinden dit soort operaties a-relaxt. Je gegevens zijn namelijk (zelfs) niet in de eerste normaalvorm. Kijk nog eens naar je databasestructuur.

Het databasemodel is idd niet goed, maar het is wel degelijk in de eerste normaalvorm.

[Verwijderd]

Verwijderd schreef op woensdag 30 maart 2005 @ 10:35:
Databases vinden dit soort operaties a-relaxt. Je gegevens zijn namelijk (zelfs) niet in de eerste normaalvorm. Kijk nog eens naar je databasestructuur.

Databases moeten niet zeuren, die moeten werken met hun kadaver.
Maar leg idd eens uit hoe jij aan deze vraag kan zien dat de structuur niet deugt?

[Verwijderd]

curry684 schreef op woensdag 30 maart 2005 @ 10:37:
[...]

Hoe de n**k destilleer je uit de gegeven informatie dat het datamodel fout is?

Zomaar een paar vragen:

• Wat voor info staat er in het veld ?
• Is het 7e character iets bijzonders ?
• Waarom is het altijd een punt ?
• Waarom heb je het nodig als je weet dat het een punt is ?
• Wat is het verband tussen (de 7e) positie en de punt ?
• Wat staat er voor en wat staat er na de punt ?

Wanneer het veld iets bevat als de optelsom van bestandsnaam + punt + extensie kan ik begrijpen dat de huidige structuur acceptabel is. Het kan natuurlijk ook een of ander repeterend veld zijn met alle geneugten van dien.

[GoodspeeD]

Verwijderd schreef op woensdag 30 maart 2005 @ 11:55:
[...]


Zomaar een paar vragen:

• Wat voor info staat er in het veld ?
• Is het 7e character iets bijzonders ?
• Waarom is het altijd een punt ?
• Waarom heb je het nodig als je weet dat het een punt is ?
• Wat is het verband tussen (de 7e) positie en de punt ?
• Wat staat er voor en wat staat er na de punt ?

Wanneer het veld iets bevat als de optelsom van bestandsnaam + punt + extensie kan ik begrijpen dat de huidige structuur acceptabel is. Het kan natuurlijk ook een of ander repeterend veld zijn met alle geneugten van dien.

Het hele veld is een statusveld m.b.t. een order en is opgebouwd uit 30 karakters. Elke positie kan verschillende karakters hebben welke de status van de order aanduidt, zoals ik al eerder aangaf, niet echt een goed datamodel, maar wel in de eerste normaal vorm.

[curry684]

Verwijderd schreef op woensdag 30 maart 2005 @ 11:55:
[...]


Zomaar een paar vragen:

• Wat voor info staat er in het veld ?
• Is het 7e character iets bijzonders ?
• Waarom is het altijd een punt ?
• Waarom heb je het nodig als je weet dat het een punt is ?
• Wat is het verband tussen (de 7e) positie en de punt ?
• Wat staat er voor en wat staat er na de punt ?

Wanneer het veld iets bevat als de optelsom van bestandsnaam + punt + extensie kan ik begrijpen dat de huidige structuur acceptabel is. Het kan natuurlijk ook een of ander repeterend veld zijn met alle geneugten van dien.

Boeiend, als ik lekker factuurnummers van 15 karakters wil genereren waarbij op positie 7 per definitie een punt staat omdat er toevallig de DDMMYY datum voorstaat dan doe ik dat, en dat kan in een 0NV, 1NV, 2NV, 3NV, 4NV en 5NV probleemloos. En als die domme secretaressemiep een paar weken lang alle facturen met een komma heeft ingevoerd behalve met een punt heb ik ook een tooltje nodig om in alle factuurnummers een punt op positie 7 te zetten.

Ik bedoel vooral te zeggen dat je extreem voorbarig was met conclusies trekken op basis van informatie die je helemaal niet had, en dat is naast zwaar offtopic ook nogal vijandig in een topic als dit.

[Verwijderd]

curry684 schreef op woensdag 30 maart 2005 @ 12:15:
[...]

Boeiend, als ik lekker factuurnummers van 15 karakters wil genereren waarbij op positie 7 per definitie een punt staat omdat er toevallig de DDMMYY datum voorstaat dan doe ik dat, en dat kan in een 0NV, 1NV, 2NV, 3NV, 4NV en 5NV probleemloos. En als die domme secretaressemiep een paar weken lang alle facturen met een komma heeft ingevoerd behalve met een punt heb ik ook een tooltje nodig om in alle factuurnummers een punt op positie 7 te zetten.

Het hangt er van af wat het tooltje kan. Als het pure SQL is, dan is de database beter genormaliseerd. Uit eigen ervaring: een outer join op het derde woord van rechts is niet relaxt.

Ik bedoel vooral te zeggen dat je extreem voorbarig was met conclusies trekken op basis van informatie die je helemaal niet had, en dat is naast zwaar offtopic ook nogal vijandig in een topic als dit.

Dit ben ik niet met je eens. Als er gebruik gemaakt moet worden van substr() operaties is de database per definitie niet in de eerste normaal vorm. Dat hoeft zeker niet alleen maar nadelen te hebben. Textvelden hebben ook hun charmes.

Mijn lijst met vragen had ik anders kunnen formuleren. Bovenstaande lijst drukt mijn methode van werken uit. Wie zich hierdoor aangevallen voelt: mijn excuses hiervoor.

[curry684]

Verwijderd schreef op woensdag 30 maart 2005 @ 12:46:
[...]

Het hangt er van af wat het tooltje kan. Als het pure SQL is, dan is de database beter genormaliseerd. Uit eigen ervaring: een outer join op het derde woord van rechts is niet relaxt.

Waarom zou je erop willen joinen? Het feit dat je data in een database moet wijzigen zegt nog niets over de manier waarop de relationele structuur van de tabel in mekaar zit

[...]

Dit ben ik niet met je eens. Als er gebruik gemaakt moet worden van substr() operaties is de database per definitie niet in de eerste normaal vorm.

Voor zover ik zie voert ie een eenmalige update uit, geen joins of wat dan ook. Het veld wat ie moet updaten kan dus alles zijn. 1NV stelt enkel dat er geen repeterende velden in de tabel mogen zitten (denk aan Kind1, Kind2, Kind3 in een tabel met Ouders), wat dus compleet ongerelateerd is.

Nogmaals: het feit dat ie in 1 veld zonder relaties te geven gegevens moet wijzigen zegt niets over de toegepaste normalisatie. For all we knew uit de openingspost was het een 5NV database

Wie zich hierdoor aangevallen voelt: mijn excuses hiervoor.

Mjah mijn term 'vijandig' was ook wat overdreven Ik bedoelde vooral te zeggen dat je een stellige uitspraak deed over dingen waar je niets over kon weten en daarmee de topicstarter onnodig verwart.

[GoodspeeD]

Verwijderd schreef op woensdag 30 maart 2005 @ 12:46:
Als er gebruik gemaakt moet worden van substr() operaties is de database per definitie niet in de eerste normaal vorm.

Dat is simpelweg niet waar. Lees de definitie van 1NF nog maar eens een keer.

[Verwijderd]

GoodspeeD schreef op woensdag 30 maart 2005 @ 13:30:
[...]

Dat is simpelweg niet waar. Lees de definitie van 1NF nog maar eens een keer.

1NF heeft met ondeelbaarheid te maken. Functies als Substr() ontkennen ondeelbaarheid.
Wat ondeelbaarheid is, kan natuurlijk bediscussieerd worden. Hier is bijvoorbeeld een korte toelichting over de ondeelbaarheid van datumvelden. In het geval van het statusveld in jouw database zou ik zeker niet spreken van ondeelbaarheid.

[Verwijderd]

ik snap totaal niet vanuit welk referentiekader jij de discussie voert, bloog. Ik heb namelijk het idee dat we langs elkaar heen zitten te praten.
Wat ik niet snap in je betoog is waarom je geen update op een veld mag doen met behulp van een SUBSTR? Waarom is daarmee een datamodel niet meer ondeelbaar (wat ik trouwens met 8 jaar RDBMS ervaring ook niet helemaal snap)?
Benader jij het zuiver academisch? Want vanuit dat oogpunt kan ik me voorstellen dat een update op de database zoals in de situatie die curry684 (domme secretaresse zit de hele dag foute gegevens in te voeren) een ondenkbare situatie is.
Maar ik kan me nu niet anders voorstellen dan dat je in de praktijk een mass-update op de database mag doen met built-in functies zonder daarmee de structurele integriteit of datamodel geweld aan te doen.

[curry684]

Korte samenvatting:

Verwijderd schreef op woensdag 30 maart 2005 @ 13:49:
[...]

Als je Substr() in een willekeurige query gebruikt heb je je database niet genormaliseerd.

Uhm sorry maar dit is echt onzin en dat ga ik niet eens beargumenteren

[Gé Brander]

Ik denk dat bloog niet alleen op afzonderlijke entiteiten normaliseert, maar ook nog eens naar wat die entiteiten als waarde kunnen bevatten. Als alles in een specifieke entiteit altijd begint met een bepaalde string/waarde, dan doet bloog dus die entiteit opdelen in twee entiteiten. (Lijkt mij overigins niet echt de bedoeling van normaliseren)

correct me if I am wrong

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

[curry684]

c70070540 schreef op woensdag 30 maart 2005 @ 14:03:
Ik denk dat bloog niet alleen op afzonderlijke entiteiten normaliseert, maar ook nog eens naar wat die entiteiten als waarde kunnen bevatten. Als alles in een specifieke entiteit altijd begint met een bepaalde string/waarde, dan doet bloog dus die entiteit opdelen in twee entiteiten. (Lijkt mij overigins niet echt de bedoeling van normaliseren)

Kern van mijn betoog is dat dat soms je reinste onzin is

Stel dat ik een frontend-administratiedatabase heb die data hotsynct vanuit een SAP backend. SAP bevat de gegenereerde factuurnummers, in het formaat "DDMMYY-KLANTID/ORDERID". De frontend DB waar de secretaresses en administratie mee werken is dus al volgepopuleerd. Het feit dat het factuurnummer als varchar(x) in die DB staat is perfect terecht omdat het als geheel een factuurnummer is, en in die DB de achterliggende betekenis van het ding niet bestaat: die bestaat enkel in SAP en in de frontend DB is het gewoon een string die toevallig op de factuur staat en waarmee je makkelijk kunt zoeken. Nu fuseer je met een bedrijf dat jouw facturen niet kan inlezen zolang er streepjes in de database staan. SAP wordt veranderd dat ie daar puntjes genereert, en goh, grote eenmalige update over heel de frontend-database om alle historische facturen in het nieuwe formaat te zetten. Volstrekt valide.

Compleet fictief, maar er zijn nogmaals zo veel situaties te bedenken waarin de vraag uit de topicstart volstrekt valide kan zijn voor een database in 5NV!

[Verwijderd]

@c70070540 : Da's theoretisch heel mooi maar in de praktijk volstrekt overbodig en onhandig. In het ergste geval kan je nog een generieke functie schrijven die die gegevens voor je omsmurft, maar ik zou daar je datamodel ab-so-luut niet voor misbruiken
En zoals curry nog eens mooi zegt..... de praktijk is weerbarstiger dan de theorie!

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

[Gé Brander]

c70070540 schreef op woensdag 30 maart 2005 @ 14:03:
(Lijkt mij overigins niet echt de bedoeling van normaliseren)

Let op deze opmerking. Ik heb nooit bedoelt te zeggen dat het juist is wat bloog schreef. Ik heb alleen gemeld wat ik dacht dat hij/zij bedoelde...

[Verwijderd]

c70070540 schreef op woensdag 30 maart 2005 @ 14:19:
[...]

Let op deze opmerking. Ik heb nooit bedoelt te zeggen dat het juist is wat bloog schreef. Ik heb alleen gemeld wat ik dacht dat hij/zij bedoelde...

ja dat begreep ik wel maar jij verduidelijkte het idd voor mij.

[GoodspeeD]

Verwijderd schreef op woensdag 30 maart 2005 @ 13:49:
[...]


1NF heeft met ondeelbaarheid te maken. Functies als Substr() ontkennen ondeelbaarheid.
Wat ondeelbaarheid is, kan natuurlijk bediscussieerd worden. Hier is bijvoorbeeld een korte toelichting over de ondeelbaarheid van datumvelden. In het geval van het statusveld in jouw database zou ik zeker niet spreken van ondeelbaarheid.

1NF heeft niet met ondeelbaarheid te maken.

M'n boek van school ligt thuis, maar de eerste hit op google toont het volgende:
"1NF: You need to have a "Proper" relation. That means the table should have no "repeating groups" of fields, and have a valid Primary Key."

Mijn tabel heeft een primary key en een geen herhalende velden. Perfect 1NF dus.

Volgens de beschrijving die op jou link staat, zou mijn tabel niet in 1NF staan, maar zo heb ik het nooit geleerd. In mijn boek staat ook niets over samengestelde velden bij het hoofdstuk normaliseren.

[ Voor 24% gewijzigd door GoodspeeD op 30-03-2005 16:47 ]

[MSalters]

Wikipedia heeft ook de andere definitie, daar is 1NF (ook) een aanduiding van atomic velden. Atomic is echt ondeelbaar. "DDMMYY-KLANTID/ORDERID" is dat per definitie niet: je geeft zelf al de delen aan.

Kind1,Kind2,Kind3 is ook in strijd met 1NF, want ook weer geen atomaire data. Het is in feite 1 lijst. Alleen, dit is op tabel nivo niet atomair, terwijl "DDMMYY-KLANTID/ORDERID" niet atomair is op kolom nivo.

Om heel eerlijk te zijn is 1NF een erg vage kreet voor iets wat eigenlijk vrij fundamenteel is.

[curry684]

MSalters schreef op woensdag 30 maart 2005 @ 18:11:
Wikipedia heeft ook de andere definitie, daar is 1NF (ook) een aanduiding van atomic velden. Atomic is echt ondeelbaar. "DDMMYY-KLANTID/ORDERID" is dat per definitie niet: je geeft zelf al de delen aan.

Om op m'n punt terug te komen: die waarde is arbitrair, voor een administratiesystem kan het ook [0-9]{6}-[A-Za-z0-9]{5}/[A-Za-z0-9]{5} zijn, puur omdat ie de achterliggende data kent noch beheert. Denk aan de ontvanger van de factuur of de deurwaarder: voor hem is het wel degelijk een atomair stuk data dat toevallig in een varchar(32) oid staat.