[SQL] correct database ontwerp ?

[codemann]

Ik ben een registratiesysteem aan het uitwerken voor een hosting provider, maar ik twijfel of mijn database ontwerp wel in orde is. Laat me even de situatie schetsen :

Ik zal beginnen met wat het laatste schema isd dat ik op papier heb, of toch het deel ervan wat van belang is :

[DOMAINS]
ID
NAME
EXT_ID
REG_TYPE_ID

[DOMAIN_REGISTRATIONS]
ID
REG_DATE
EXP_DATE
REG_YEARS
ORDER_YEARS
PRICE
REGISTRAR_PRICE

[DOMAIN_OPTIONS]
ID
ACTIVATION_DATE
HOSTING_ID
NS1_ID
...

[INVOICES]
ID
INVOICE_NR
INVOICE_DATE
PRICE
PAY_TYPE
PAY_DATE

[ORDERS]
ID
INVOICE_ID
ORDER_NR
ORDER_DATE
ORDER_STRING
DOMAIN_ID
DOMAIN_REG_ID
DOMAIN_OPTION_ID

Ik ben dus niet zeker of dit wel de ideale manier is. Ik kan me voorstellen dat het voor sommigen raar lijkt dat er zo veel "dates" in voorkomen. Wel, de hosting provider wil (zeer veel) historieken bijhouden zodat hij heel goed kan controleren wat er allemaal gebeurd is met hostings/domeinen.

Wat extra uitleg :
Laten we beginnen bij het domein. Deze heeft een naam (bijv. tweakers) en een extentie-id. Ook het registratie-type wordt bijgehouden, dit is hoe het domein terecht gekomen is bij de hosting provider (nieuwe registratie - transfert - ...).
In domain_registrations staat dan de informatie over de registratie van het domein: wanneer deze is gebeurd, wat de expiration date is, ... Domain_options bevat alle informatie over wat er aan het domein hangt: een hosting, een forwarding, ...
Verder zijn er nog de invoices (facturen) met al hun informatie. En aan een factuur hangen dan 1 of meerdere orders. Dit is ook zo in de bestaande boekhouding dus dat leek me de beste oplossing.
Omdat er bij een upgrade van de hosting bijvoorbeeld de registration informatie ongewijzigd blijft en dus enkel de options veranderen heb ik in de orders tabel een verwijzing naar het domein, de registratiegegeven en de options gestoken. Als ik dan alle orders van een bepaald domein opvraag kan ik mooi een historiek verkrijgen. In ORDER_STRING staat de string zoals hij van de ASP applicatie komt. Aan de hand van die string kan ik dus EXACT zien wat er toen besteld is en de combinatie van DOMAIN_REG_ID en DOMAIN_OPTION_ID geeft me ook weer exact de laatste gegevens over wat die klant van dat domein heeft bij de provider.
Voor degenen die denken van maar allez hij is de koppeling met de klanten vergeten, dit is zeker niet het geval. Dit gebeurt in andere tabellen die aan DOMAINS hangen, maar ik ben vrij tot heel zeker dat ik dat op de best mogelijke manier heb gedaan.
Ik heb niet echt een probleem dus, maar ik voel me niet 100% met dit deel van het schema dus wou ik even iemand anders zijn mening.

Alvast bedankt!

[codemann]

Niemand hier een idee of een mening hierover? Lijkt me toch wel raar...
Ik heb de FAQ nog eens zitten nalezen of ik een fout gemaakt heb in de post, maar het lijkt toch dat ik vrij correct te werk ben gegaan.
Ondertussen heb ik wel al de database op deze manier geimplementeerd om niet stil te blijven zitten, maar suggesties zijn nog altijd meer dan welkom want mijn gevoel zegt me dat er iets niet 100% is aan dit ontwerp.
Ben ik misschien ergens onduidelijk? Alvast mijn excuses dan, je vergeet al snel iets als je zelf veel met de materie bezig bent... Zeg het maar en ik vul mijn verhaal aan.

[dip]

Misschien is het interessant om je database eens in DeZign te moddeleren. Hier kun je gelijk relaties aangeven etc.. Kies als target BMS MySQL en kijk eens wat het programma voor database genereerd.

Succes ermee

[codemann]

dip schreef op 23 September 2003 @ 08:46:
Misschien is het interessant om je database eens in DeZign te moddeleren. Hier kun je gelijk relaties aangeven etc.. Kies als target BMS MySQL en kijk eens wat het programma voor database genereerd.

Succes ermee

Bedankt, ga ik onmiddellijk eens proberen !

[SchizoDuckie]

het ziet er redelijk uit, maar wat dacht je ervan om ook een klant te koppelen aan een domeinnaam

* SchizoDuckie is al een tijdje bezig aan zo'n project, maar dan iets uitgebreider

Mijn overzichtjes genereer ik gewoon via access trouwens Mysql ODBC drivertje installen, tabellen importeren en gaan

[ Voor 23% gewijzigd door SchizoDuckie op 23-09-2003 08:54 ]

[codemann]

Papa Eend schreef op 23 September 2003 @ 08:53:
het ziet er redelijk uit, maar wat dacht je ervan om ook een klant te koppelen aan een domeinnaam

* codemann is al een tijdje bezig aan zo'n project, maar dan iets uitgebreider

Mijn overzichtjes genereer ik gewoon via access trouwens Mysql ODBC drivertje installen, tabellen importeren en gaan

Papa Eendje, zoals ik dus zei :
"Voor degenen die denken van maar allez hij is de koppeling met de klanten vergeten, dit is zeker niet het geval. Dit gebeurt in andere tabellen die aan DOMAINS hangen, maar ik ben vrij tot heel zeker dat ik dat op de best mogelijke manier heb gedaan."

Wat ik hierboven dus toon is het deel van de database waarvan ik niet zeker ben dat het de juiste oplossing is, hopende op wat reacties zodat ik het ontwerp kan bijsturen.

[SchizoDuckie]

Mjah eerlijk gezegd kan ik hier niet zoveel mee zoals het er zo uit ziet. Niet echt overzichtelijk aangezien je linkt naar ID's die niet 'op de kaart' staan

[faabman]

enige wat ik kan bedenken is een soort van notitieblok voor het betreffende bedrijf, zodat ze bij kunnen houden wat er moet klanten en/of pakketten gaande is (als ze dan toch een uitgebreidde historie bij willen houden....)

persoonlijk vind ik het gebruik van hoofdletters in je dbase errug lelijk, vergroot in mijn ogen ook niet echt de leesbaarheid van je queries

code:

SELECT NAAM, NUMMER, DATA FROM TBL_BLAAT

code:

SELECT naam, nummer, data FROM tbl_blaat

[codemann]

Papa Eend schreef op 23 September 2003 @ 09:01:
Mjah eerlijk gezegd kan ik hier niet zoveel mee zoals het er zo uit ziet. Niet echt overzichtelijk aangezien je linkt naar ID's die niet 'op de kaart' staan

Euhm ik leg in de tekst toch alles in detail uit ? Het gaat me om de tabellen die ik hier toon, de koppeling met de domeininformatie (in de tabellen [DOMAINS], [DOMAIN_REGISTRATIONS] en [DOMAIN_OPTIONS]) met de informatie op de facturen ([INVOICES] en [ORDERS]).

Dit is eigenlijk een verhaal langs 2 kanten bekeken. Je moet het verhaal kunnen beginnen met "er was eens een domein..." maar ook met "er was eens een factuur...". En als ik het zo probeer te bekijken dan voelt het aan alsof het ontwerp niet 100% is maar ik weet zelf niet meer hoe het nog te verbeteren. Misschien raar uitgelegd, ik hoop dat je volgt in wat ik ermee wil zeggen.

De tabellen die ik dus niet toon zijn echt niet van belang. Ik kan er nog een 20tal tabellen aanhangen als je wilt maar dan gaat denk ik mijn "probleem" in die zee van tabellen verloren gaan. (damn ik ben poëtisch zo vroeg op de morgen )

[dip]

codemann probeer het eerst te moddelleren met deZign of access.
Post je results hiero en we kijken er ff naar.

[codemann]

FvKnijff schreef op 23 September 2003 @ 09:08:
enige wat ik kan bedenken is een soort van notitieblok voor het betreffende bedrijf, zodat ze bij kunnen houden wat er moet klanten en/of pakketten gaande is (als ze dan toch een uitgebreidde historie bij willen houden....)

persoonlijk vind ik het gebruik van hoofdletters in je dbase errug lelijk, vergroot in mijn ogen ook niet echt de leesbaarheid van je queries

code:

SELECT NAAM, NUMMER, DATA FROM TBL_BLAAT

code:

SELECT naam, nummer, data FROM tbl_blaat

Ik was inderdaad aan het denken om een extra tekstveld toe te voegen (description/notes/...) waarin ze aan bepaalde records wat extra eigen informatie kunnen toevoegen. Als een klant dan bijvoorbeeld laat betaald heeft kunnen ze er even de reden bijzetten ofzo.
Dat bedoel je toch eh?

[faabman]

codemann schreef op 23 September 2003 @ 09:13:
[...]


Ik was inderdaad aan het denken om een extra tekstveld toe te voegen (description/notes/...) waarin ze aan bepaalde records wat extra eigen informatie kunnen toevoegen. Als een klant dan bijvoorbeeld laat betaald heeft kunnen ze er even de reden bijzetten ofzo.
Dat bedoel je toch eh?

Ja, dat bedoel ik, maar, heb je nu ook al aan de namen van je cols gedacht (UPPERCASE vs lowercase)

[codemann]

FvKnijff schreef op 23 september 2003 @ 09:15:
[...]


Ja, dat bedoel ik, maar, heb je nu ook al aan de namen van je cols gedacht (UPPERCASE vs lowercase)

Dat lijkt me een kwestie van persoonlijke smaak eh, ik heb altijd met uppercase gewerkt en dat bevalt me ook wel

[codemann]

Is het dit wat je graag had dip? Heb het even in SQL Server gemaakt voor de tabellen van toepassing, ik hoop dat het goed is.

[ Voor 57% gewijzigd door codemann op 23-09-2003 09:27 ]

[Poiter]

Ik ken de specs niet precies, dus corrigeer me als ik het verkeerd zie:

Je hebt in principe Orders.
Een order resulteert in een Domain en in een Invoice.
Bij een domein horen dan nog Domain_options en Domain_registrations.

Meerdere orders kunnen op 1 Invoice terechtkomen.

Orders <-> Invoice = n : 1
Orders <-> Domain = 1 : 1
Domains <-> Domain_options = 1 : n
Domains <-> Domain_registrations = 1 : n


Hieruit volgt :

In orders hoef je alleen Domain_id op te nemen, en kun je domain_option_id en domain_registration_id laten vallen. (want deze kun je benaderen via domain)

Verder is misschien een order_status veld handig in Orders, als een order meerdere statussen kan hebben. (dan wordt de relatie orders <-> domains misschien ook wel een een 1: 0/1 relatie.

Succes!!

[JaQ]

misschien een opmerking waar je absoluut niet op zit te wachten, maar heb je al eens naar ispman gekeken?

Ik host zelf ook (naast een aantal andere activiteiten) en ISPMan is een heel vriendelijk programa voor dit soort doeleinden. In ieder geval interessant genoeg om eens te bestuderen?

[codemann]

Poiter schreef op 23 september 2003 @ 23:36:
Ik ken de specs niet precies, dus corrigeer me als ik het verkeerd zie:

Je hebt in principe Orders.
Een order resulteert in een Domain en in een Invoice.
Bij een domein horen dan nog Domain_options en Domain_registrations.

Meerdere orders kunnen op 1 Invoice terechtkomen.

Orders <-> Invoice = n : 1
Orders <-> Domain = 1 : 1
Domains <-> Domain_options = 1 : n
Domains <-> Domain_registrations = 1 : n


Hieruit volgt :

In orders hoef je alleen Domain_id op te nemen, en kun je domain_option_id en domain_registration_id laten vallen. (want deze kun je benaderen via domain)

Verder is misschien een order_status veld handig in Orders, als een order meerdere statussen kan hebben. (dan wordt de relatie orders <-> domains misschien ook wel een een 1: 0/1 relatie.

Succes!!

Bedankt voor je reactie ! En je hebt zelfs gelijk, nog beter dus
Een order_status veld ben ik inderdaad vergeten, 2x bedankt dus zelfs !