database: algemene verzameltabel

[107mb]

Ik ben sinds kort werkzaam bij een bedrijf waar een eigen ontwikkeld ERP pakket gebruikt wordt. Tot mijn verbazing wordt er een tabel tblCodes gebruikt. in deze tabel staan een kleine 40.000 records met gegevens die eigenlijk in eigen tabellen hoort te staan.

Enkele voorbeelden:

Er bestaat een tabel tblKLachten waarin klachten worden geregistreerd:
klachtID, klachtcode, klant, enz....

er bestaan 20 klachtcodes. Ik zou dus een tabel tblKlachtcodes verwachten, maar de klachtcodes zijn dus in tblCodes opgenomen:

Nummer	groep	code	omschrijving	activiteit	activiteit2	activiteit3
14501	Klachtcode	14	Fout klant	null	null	null
14502	Klachtcode	15	Beschadigingen	null	null	null

In deze tabel staan ook eenheden, veldnamen, productiegegevens om machines aan te sturen, producteigenschappen enz. enz.

Ik heb het idee dat de programmeur een hekel heeft om nieuwe tabellen te maken, en bestaande tabellen uit te breiden en dus daarom deze verzamelbak heeft gecreeerd.

Nu ben ik geen echte DB-engineer, maar het komt mij erg vreemd over. Zijn er tweakers die dit eerder hebben gezien? Wat moet ik hier van vinden? zijn er argumenten om zo'n constructie te rechtvaardigen?

Omdat ik zonder functie of subquery geen fatsoenlijke join kan maken wil ik de in de tabel tblCodes aanwezige data zoveel mogelijk in tabellen gaan onderbrengen....

[Rannasha]

Welke database software draait er? Als dat SQL Server is, dan kun je kijken naar iets als SQL Server Integration Services (SSIS) om iets in elkaar te schroeven dat de huidige database aanpakt en de boel in een bruikbaardere structuur brengt. Dit is een uitbreiding van Visual Studio. Daarnaast kun je natuurlijk altijd handmatig de queries opstellen om de structuur te herzien.

Er zijn niet echt goede argumenten om de huidige structuur te rechtvaardigen, behalve luiheid en/of een gebrek aan vooruitdenken van de persoon die dit zo heeft opgezet. Met de huidige structuur kun je tegen problemen aanlopen dat als, bijvoorbeeld, de laatste record van klachtcode 15 verwijderd wordt, je opeens geen omschrijving meer hebt die bij klachtcode 15 hoort.

[107mb]

Frontend is Access
DB is Postgres

de database is trouwens helemaal merkwaardig opgezet. Heel veel multivalue velden, niet genormaliseerde tabellen, bijna niet gebruik gemaakt van foreign keys, enz. enz.

[Verwijderd]

Performance zou een reden kunnen zijn met een beetje fantasie. Maar met maar 40k regels is dit niet te rechtvaardigen.

Wat ik me wel afvraag is waar de inhoud van de kolommen code en omschrijving vandaan komen. Ik neem aan dat de gebruiker deze niet zelf invoert. Toevallig ingebakken in de gui?

[ Voor 4% gewijzigd door Verwijderd op 17-10-2014 13:45 ]

[107mb]

vulling wordt door de huidige programmeur gedaan. Het betreft voornamelijk informatie zoals ik beschreven heb. Maar ook data voor listboxen, printinstellingen voor alle printers, layout instellingen voor rapporten, inclusief een eigen scripttaal die in de velden activiteit, activiteit2 en activiteit3 staan.

eigenlijk staat er alle soorten informatie in, die gewoon in tabellen hoort te staan.

[ Voor 4% gewijzigd door 107mb op 17-10-2014 14:12 ]

[MSalters]

Bekende fout, heeft zelfs een naam : "Inner Platform Effect". Om één of andere reden maken veel junior developers dezelfde fout, in het bijzonder zij-instromers in de ICT. De meeste opleidingen vertellen je dit niet te doen.

[P_Tingen]

Ik ken hem onder de naam "One True Lookup Table". Als je er even op zoekt, kom je in de meest vermakelijke discussies terecht. Het is voornamelijk gemakzucht van de ontwikkelaar en / of angst om nieuwe tabellen aan te maken. Wanneer je in een bedrijfscultuur zit met een Bastard DBA From Hell, dan kan ik me er nog iets bij voorstellen ook.

In het bedrijf waar ik werk, wordt gewerkt met een ERP pakket van QAD. Hier zit ook een generieke code tabel in, met de naam "generalized codes". Soortgelijke opbouw. Tijdens het ontwikkelen is het wel makkelijk moet ik toegeven. Het systeem biedt al lookup functionaliteit dus het enige wat ik hoef te doen wanneer ik een veld introduceer met een beperkte set aan mogelijke waardes is het veld koppelen aan de generalized codes, daar waardes inzetten en klaar.

De discussie omtrent OTLT is wat mij betreft dan ook niet zo zwart-wit. Als je de waardes in die tabel wil koppelen aan andere tabellen, is het niet een goed idee, maar wanneer waardes alleen als attribuut voorkomen in andere tabellen en alleen dienst doen om een lookup makkelijk te vullen, bv iets triviaals als "betaalwijze" of zo, dan kan het prima in een generieke tabel.

Tot het moment natuurlijk dat je nóg iets anders wil vastleggen per betaalwijze, bijvoorbeeld standaard korting per betaalwijze. Dan ben je de Sjaak en gaat het je niet meer lukken met je generieke tabel. Tenminste niet als je er niet helemaal een puinhoop van wil maken. Als je in jullie geval van klachtcodes nog iets anders vast wil leggen (bv standaard prioriteit, maximum reactietijd etc), dan zou ik de waardes uit de generieke tabel halen en een eigen tabel geven.

Edit: voordat ik hier met pek en veren word afgevoerd, hier wat interessant leesvoer over de voor- en nadelen. Onderstreept mijn punt een beetje.

Edit 2: OTLT's zijn eigenlijk net Beerenburg; als je het met mate gebruikt, kun je er veel lol aan beleven

[ Voor 8% gewijzigd door P_Tingen op 17-10-2014 20:06 ]

[Gomez12]

Tja, ik weet het niet. Het is heel erg afhankelijk in mijn idee. En compleet afhankelijk van de data die erin staat.
Qua klachtcodes vind ik het onbegrijpelijk, maar bijv onderstaande kan ik mogelijkerwijs nog wel begrijpen

107mb schreef op vrijdag 17 oktober 2014 @ 14:07:
Maar ook data voor listboxen, printinstellingen voor alle printers, layout instellingen voor rapporten, inclusief een eigen scripttaal die in de velden activiteit, activiteit2 en activiteit3 staan.

Even aangenomen dat printinstellingen geen daadwerkelijke printerinstellingen zijn maar printersoortinstellingen (bijv kleurenprinterinstellingen, laserprinterinstellingen, matrixprinterinstellingen)
Want dat soort instellingen zijn over het algemeen qua data zo goed als statisch en is veelal extreem klein.

Maar ik zou zeggen doe eens een group by op waarop jij hem uitgesplitst zou willen zien en kijk dan wat eruit komt. Als daaruit blijkt dat er bijv 2000 tabellen komen met gemiddeld 20 items, tja dan heb ik liever een algemene tabel dan dat ik 2000 mini-tabelletjes heb die me enkel in de weg zitten qua db-schema.

Of zoals ik het altijd aan stagaires vertel : Wij maken nieuwe tabellen als :
- Het een nieuwe entiteit betreft
- Die of in zijn levensduur meer dan 50 elementen kan gaan bevatten
- Of als het unieke eigenschappen heeft.

Het enige nadeel met deze tabel is dat als ik het goed lees die activiteit kolommen mijn criteria van unieke eigenschappen bijna altijd zal raken (eigen scripttaal moet je niet in een dbase zetten)

[P_Tingen]

Ja, die activiteitkolommen vind ik ook wat vreemd. In onze database zijn er ook een paar "extra" velden waar je "iets anders" in kan zetten. Dat "iets anders" kan van alles zijn en moet je in de programmatuur afvangen.

Wie dat bedacht heeft moet met terugwerkende kracht in zijn ballen geschopt worden want het geeft aan dat je dus kennelijk "iets exta's" wil vastleggen van die generieke code. Daarmee is het geen domme statische code meer maar neigt het naar een entiteit. Ik zou best een algemene codetabel willen verdedigen maar dan alleen als het een kwestie van drie velden is: groep, code en omschrijving. Als je meer wil vastleggen heeft het recht op een eigen tabel.

[107mb]

wauw, erg interessante feedback!

de ontwikkelaar is inderdaad een zij-instromer. op leeftijd. Wel een intelligent man. Ik ga eens op onderzoek, hoeveel unieke codegroepen er zijn, en wat in bestaande tabellen opgenomen kan worden. Het probleem is natuurlijk dat het pakket relatief klein begoon, en er in de loop der jaren heel veel is bijgekomen.

er zijn zo'n 350 verschillende groepen met totaal 40.000 records. maandag maar eens een verdeling gaan maken, van wat in tabellen moet, en de rest kan blijven bestaan.

[P_Tingen]

Ik zou me eerst richten op die records / recordgroepen waarbij de "activiteit" velden een waarde hebben. Dat zijn records die eigenlijk entiteiten zijn. De andere records kunnen dus kennelijk bestaan met als velden alleen groep, code en omschrijving en zijn dan ook kandidaat voor je lookup table.

Ik wil nog kwijt dat er in zo'n situatie altijd een goede reden is om gegevens naar een eigen tabel te verhuizen en er eigenlijk nooit een reden is om dat /niet/ te doen.

[Tribits]

107mb schreef op vrijdag 17 oktober 2014 @ 11:09:
...
In deze tabel staan ook eenheden, veldnamen, productiegegevens om machines aan te sturen, producteigenschappen enz. enz.

Ik heb het idee dat de programmeur een hekel heeft om nieuwe tabellen te maken, en bestaande tabellen uit te breiden en dus daarom deze verzamelbak heeft gecreeerd.

Nu ben ik geen echte DB-engineer, maar het komt mij erg vreemd over. Zijn er tweakers die dit eerder hebben gezien? Wat moet ik hier van vinden? zijn er argumenten om zo'n constructie te rechtvaardigen?

Omdat ik zonder functie of subquery geen fatsoenlijke join kan maken wil ik de in de tabel tblCodes aanwezige data zoveel mogelijk in tabellen gaan onderbrengen....

Wat ik me na deze beschrijving vooral af vraag is wat je denkt te winnen met het maken van afzonderlijke tabellen en hoeveel problemen je er mee op je nek haalt. Eigenlijk kent ieder ERP systeem dat ik gezien heb wel dergelijke eigenaardige ontwerp beslissingen / fouten. De reden dat ze er nooit uitgehaald worden is dat het in de praktijk op een vrijwel complete rewrite van het systeem neerkomt met alle gevolgen van dien.

Als je al besluit tot het omzetten van de genoemde code tabel naar afzonderlijke tabellen dan denk ik dat het verstandig is om daar je leidinggevende van op de hoogte te stellen, eventueel ondersteund door een business case / project voorstel waarin je de noodzaak van een dergelijke aanpassing aantoont/verdedigt. Op zich ben ik het er mee eens dat het een slecht ontwerp is maar dat rechtvaardigt nog niet zondermeer een dergelijk grote aanpassing. Probeer bovendien een goed inschatting te maken van de hoeveelheid werk die deze aanpassing met zich meebrengt. De kans is groot dat een dergelijke universele tabel sterk verweven is met de code die door het hele pakket heen gebruikt wordt.

De laatste regels van de OP zijn de enige verklaring waarom er een praktische noodzaak zou zijn om de tabel op te splitsen maar om eerlijk te zijn snijden die wat mij betreft weinig hout. Je kan ook tien keer joinen op dezelfde tabel. Er zijn in de rest van de reacties nog wel wat argumenten voorbij gekomen om de tabel te splitsen maar ik zie vooralsnog de voordelen niet opwegen tegen de nadelen/risico's.