Mijn data model.
ik ben een site aant maaken enga er een data base bij gebruiken ben bezig geweest met het ontwerp van datat model en dit is het geworden(zie link).
http://h1.ripway.com/rakoda/datemodel.png
Ik hoor graag jullie mening ;)
Bijvoorbeeld: primary keys, foreign keys, etc.
Welke methodiek heb je gebruikt? of heb je uit het hoofd gedaan?
foreign keys weet niet hoe dat gaat heb bijvorbeeld bij radio categorie het id staan de betrevende categorie
Gewijzigd op 01/01/1970 01:00:00 door Joey Drieling
Je hebt admin en user gescheiden zie ik. Op zich zou je die samen kunnen voegen, bepaalde gebruikers zijn admins maar voor de rest komt er een boel overeen. Maar dat hoeft niet, als je echt een gescheiden admin hebt (en de admin dus niet de website is met wat extra knopjes) dan is dit ook een goeie (veiligere?) oplossing. Heb je wel gewoon extra knopjes als admin, dan is het misschien onhandig, omdat je nu niet via een UNIQUE constraint unieke gebruikersnamen (en emailadressen?) kan garanderen.
Als wachtwoord sla ik meestal de sha1-hash van dat wat ze hebben opgegeven op. Op die manier zit er geen limiet op de gebruikte tekens en lengte van een wachtwoord, en is het niet uit de database af te leiden wat het werkelijke wachtwoord was. Een sha1-hash is altijd 40 karakters lang, dus je kan CHAR(40) daar gebruiken als kolomtype.
Waarom is position van het type VARCHAR?
Ik neem aan dat de kolom category_id in custom_station zit omdat een gebruiker zelf een bestaand radiostation in een andere categorie voor zichzelf kan indelen?
Je kunt beter een ontwikkelmethodiek gebruiken zoals FCO-IM.
Het heeft een nogal steile leer-curve maar is veel beter dan uit het hoofd.
Als je het goed doet komt er altijd een geldige relationele database uit, en eerlijkgezegd denk ik niet dat die van jou dat is.
Voor een FCO-IM casetool moet je even zoeken naar infgon. de beta is gratis te downloaden.
Heb je misschien een relatiediagram voor je ontwerp??
category:
position klinkt als een getal, waarom is het dan een varchar?
radio_stations:
radio_url waarom een TEXT, zijn die urls zo lang?
radio_streaml waarom een TEXT, zijn die streams zo lang?
position klinkt als een getal, waarom is het dan een varchar?
custom_stations
position klinkt als een getal, waarom is het dan een varchar?
country:
coun_name maar 30 lang? Ik dacht dat er landen met van die samengestelde namen waren (bijvoorbeeld: Voormalige Joegoslavische Republiek Macedonië al is die naam niet de officiële)
admin:
admin_pass maar 20 lang, hoe sla je het op? Een beperking van 20 voor een wachtwoord kan eventueel, maar waarom niet als een (salted) hash opslaan?
user:
user_pass maar 20 lang, hoe sla je het op? Een beperking van 20 voor een wachtwoord kan eventueel, maar waarom niet als een (salted) hash opslaan?
Wat is je verschil tussen user en admin? Is er een rede om er 2 tabellen van te maken? Er is nu namelijk geen verschil te zien. Dan zou je gewoon 1 tabel kunnen doen met boolean admin. Verder is het de vraag hoe uitgebreid moet het worden. Wordt het groot dan is een daadwerkelijk rechten systeem wel handig.
Gewijzigd op 01/01/1970 01:00:00 door TJVB tvb
http://h1.ripway.com/rakoda/datemodel2.png
ik heb admin en user apart omdater een aparte admin interface komt apart van de site waar ik als admin alles kan beheeren toevoegenveranderen en verwijderen en ik alle rechten heb.
vond het dus ook veiliger.
Verder is het handig om na te denken over de relaties. Je hebt nu relaties in gedachten tussen bijvoorbeeld user en country, maar je moet die relatie nog een beetje uitwerken. Bijvoorbeeld: is user.cout_id verplicht, of mag hij ook NULL zijn. Wat moet er gebeuren met de row in country wanneer een er een user wordt verwijdert die naar die row verwijst (niets als het goed is :P ) maar belangrijker, wat moet er met de rows in user gebeuren wanneer de row in country waaraan ze gekoppeld zijn verdwijnt? Moet dan user.cout_id op NULL worden geset, of moeten al die user-rows ook verwijderd worden?
Hetzelfde geldt voor je radio en custom_radio tabellen, en al je andere relaties.
maakt extreem weinig uit waar je data staat, als je je script maar goed beveiligd.
als ze in je DB kunnen kunnen ze overal bij.
gewoon een veldje met rechten toevoegen.
bijvoorbeeld 1 is een admin en 0 is een user.
Als het dezelfde database is zal het op gebied van veiligheid niks uitmaken.
En heb je ook naar foreignkeys gekeken?
http://h1.ripway.com/rakoda/datemodel3.png
als een country of language verwijdrt word komt bij user op standert engels testaan.
als een radio zender verwijdert wordt dan verandrt er niks bij cutom_sttions als de user dan op die zender kikt komt er een melding dat die zende verwijdert is.
foreignkeys nooit van gehoord heb gegoogled maar word er niks weizer van
iemand korte uitleg.
Gewijzigd op 01/01/1970 01:00:00 door Joey Drieling
staat genoeg info op het internet, anders even in rapid library (rapidshare search) zoeken naar het e-book van SQL de basis (of het voor 2 tientjes bijd e stumpel halen morgen)
Zoals je zelf zegt wil je melden dat het station verwijderd is, dan kan je denk ik het beste in die situatie cusomt_radio.radio_id op NULL zetten. Dat is logischer dan een naar niets verwijzend getal :) (en je krijgt geen vreemde koppelingen in het op zichzelf al vreemde geval dat een eerder verwijderd id in de radio-kolom hergebruikt wordt)
coun_codes zijn toch altijd 2 letters? Dan kan je CHAR gebruiken in plaats van VARCHAR. Klein detail maar hoor :)
en lees inder daad even die innoDB tut door. zeer handig en voorkomt dit soort fouten.
http://h1.ripway.com/rakoda/datemodel4.png
PK = PRIMARY KEY
FK = FOREIGN KEY
* = NOT NULL
Maar voordat je je gaat vervelen mag je nu nog wel nadenken over de indexes. Niet dat dat echt heel hard nodig is omdat bij iedere FK automatisch een index meekomt (moet van InnoDB) maar je kan overwegen om bijvoorbeeld een UNIQUE index op de user_name te gooien, of op de combinatie van user_id & radio_id in custom_radio.
Verder kan je nog nadenken wat er precies moet gebeuren met de FOREIGN KEYS bij een DELETE of een UPDATE van de aan hun gekoppelde PRIMARY KEY. Zoals ik eerder al zei, moeten ze mee updaten/verwijderen, of leeg worden.
En als je dan echt niets meer te doen hebt, kan je nadenken over de queries. De SELECT queries zijn redelijk standaard, met wat JOINS maar niets extra ingewikkelds. De INSERT of UPDATE queries moet je misschien nog even over nadenken, aangezien je met dat position-veldje zit. Hoe ga je ervoor zorgen dat die de goeie waarden houden bij het verplaatsen en verwijderen van stations? (Ze hoeven natuurlijk niet exact naast elkaar te liggen, ze mogen ook 1, 3, 5, 6, 8 zijn, zolang je er maar op kan sorteren)
http://h1.ripway.com/rakoda/create.sql
alles wat van uit de admin word geupdate moet oveal natuurlijk ook ge update worden.
wt verwijdert word word alles geupdate behalve bij custo_stations die krijgteen melding als iet verwijdert is of verandert en kunne het dan zelf hun custom station verwijderen of aanpassen.
betreft postion alles word uit data base gehaald van betrevende user alles krijgt nieuwe position bij opslaan dus als door verwijdering position 6 mist word dat op gelost waneer de user de volg orde aanpast.
PS de volg orde kan verandert woren via mootools drageble autosave
maar hoe ik de queries ga aan paken dat word nog effe wat tutoriels doornemen.
Gewijzigd op 01/01/1970 01:00:00 door Joey Drieling