[MySQL] Nieuwe Stijl

[Verwijderd]

Ben met versie 2 bezig van een video site en zat na te denken. Nu is mijn database structuur een puinzooi.

Ik wil me mening delen met andere. Hoe ik het hieronder heb denk ik dat het gewoon perfect is. maar iemand anders zei dat ik beter kortere kolomnamen kon gebruiken? maar aan de andere kant is dit voordelig met inner joins hoe het nu is?



ik wil jullie mening eens graag horen? en suggesties?

Alvast bedankt.

[rvanlooijen]

Ik zal het eens doorlopen en kijken wat me opvalt:

- Waarom hebben alle properties de entity as prefix? Niet geweldig nuttig en veel typwerk.
- Ik zie geen relaties? Hierdoor is het lastig om te zien of de algemene structuur op orde is,
met de juiste kardinaliteiten en wat garnering zoals cascades enzo kan je het jezelf een stuk duidelijker/makkelijker maken.
- De user in de entiteit video is niet als foreign key gedefinieerd.
- Het bijhouden van totalen in de losse tabellen vind ik op zn zachtst gezegd raar. Deze waarden kan je eenvoudig on the fly berekenen, eventueel makkelijk met views. Mocht je echt performance issues hebben kan je ze altijd in een aparte tabel mikken met wat stored procedures om ze te updaten.
- Al je datums sla je op als ints, ik neem aan dat je hier timestamps in wilt stoppen. Op zich een prima oplossing maar een date veld is wat makkelijker uit te lezen icm andere programmeertalen wellicht.
- Er valt nog aardig wat te normaliseren, hoewel je hier natuurlijk zelf de keuze's in maakt. Voorbeeld: Als 99% van je gebruikers uit NL komt en dat allemaal zelf typen...
- Waarom is user_level in godsnaam een varchar? Wil je hier iets engs inzetten als 'admin' en 'modje' ofzo? Kies voor een uitgewerkte structuur met policies of 'gewone' authlevels, waarin je werkt met ints van 0 tot x.
- Heroverweeg bepaalde datatypen zoals een varchar voor rating (??!) en een varchar voor e-mail. In principe kan een e-mail adres namelijk langer dan 255 chars zijn.
- In video is je (overigens niet gedefinieerde) foreign key de username, dit zou een userid moeten zijn neem ik aan?
- De tabel video_search snap ik niet helemaal, je wilt hierin alle unieke keywords uit searches in opslaan, waarom? Je kunt zo bijvoorbeeld niet achterhalen hoe vaak er op iets gezocht is.
- Enkele tabellen hebben geen primairy key?
- Wees iets conservatiever met je indexen, het nut van een INDEX_COMMENTS bijvoorbeeld is mij niet direct duidelijk.

Succes met reviseren, reviseren en nog eens reviseren!

[wackmaniac]

Dat van de prefixes vind is iets wat ik zelf ook wel geregeld gebruik. Als je meerdere velden hebt met eenzelfde naam, zeg een `id`, en je gaat joinen is het wel handig dat je verschillende namen hebt. Althans dat is mijn mening. Ik weet uit ervaring dat anderen dit niet vinden en dat zij in joins graag de tabllen benoemen. Maar het argument van typwerk vind ik een beetje een nonsens argument. Als je toch een hele applicatie bouwt, dan is het kleine beetje typwerk dat je hieraan kwijt bent te verwaarlozen.

Met de overige argumenten van Ceasartje ben ik het wel eens.

[Janoz]

Die prefixes zijn helemaal niet nodig. Bij joins kun je het veld name en id in de tabel user ook gewoon aanspreken als user.name en user.id. Net zoveel typewerk en imho wat netter.

[TwoR]

wackmaniac schreef op zondag 09 september 2007 @ 11:25:
Dat van de prefixes vind is iets wat ik zelf ook wel geregeld gebruik. Als je meerdere velden hebt met eenzelfde naam, zeg een `id`, en je gaat joinen is het wel handig dat je verschillende namen hebt. Althans dat is mijn mening. Ik weet uit ervaring dat anderen dit niet vinden en dat zij in joins graag de tabllen benoemen. Maar het argument van typwerk vind ik een beetje een nonsens argument. Als je toch een hele applicatie bouwt, dan is het kleine beetje typwerk dat je hieraan kwijt bent te verwaarlozen.

Met de overige argumenten van Ceasartje ben ik het wel eens.

ik vind het juist makkelijk dat alle velden een ID veld hebben, en dat een datum als bijvoorbeeld date wordt opgeslagen. Je weet dan van alle tabellen dat er een standaard naamgeving/structuur is.

En in een join gebruik je dan toch gewoon `table1`.`ID` AS table1ID en `table2`.`ID` as table2ID

[curry684]

Janoz schreef op zondag 09 september 2007 @ 11:31:
Die prefixes zijn helemaal niet nodig. Bij joins kun je het veld name en id in de tabel user ook gewoon aanspreken als user.name en user.id. Net zoveel typewerk en imho wat netter.

Daar zijn de meningen over verdeeld, ik vind het zelf zot om in iedere tabel een primary key met exact dezelfde naam te hebben, recept voor verwarring. Dus ik noem de surrogate PK per definitie tabelnaam+Id, dus UserId, RoleId, ProductId of whatever in nette Pascal-casing. Voor de rest van de velden gebruik ik daarentegen geen prefixes, da's wel redelijk loos.

In the end maakt het qua naamgeving allemaal weinig uit natuurlijk zolang je maar consequent bent en niet tegen de betere principes (geen multi-column PK's, geen twijfelachtige natural keys e.d.) schopt. Iedereen heeft nu eenmaal z'n eigen stijl, en camelcase, Pascal-case, underscore-separated e.d. zijn allemaal goed leuk en aardig zolang jij en je team er maar mee kunnen werken en 100% consequent in zijn.

[Verwijderd]

Waarom die count velden, omdat on the fly in een database met 50000 videos langzaam is.

Ikzelf werkt aan een applicatie met 24 miljoen members en ben geen DBA. maar weet wel hoe alles aan de praat te krijgen.

Werk bij een van de grootste bedrijfen online. Maar om eve verder te gaan op alles:

Het ging mij voornamelijk om de prefixs. andere suggesties heb ik weer wat van geleerd.

in het bedrijf waar ik werk worden deze prefix gebruikt. grote software pakketen phpbb/vbulletin gebruiken het op dezelfde manier. daarom zocht ik raad.

overzichtelijk, dat denk ik ervan. hoe het nu is. maar andere kant is het meer typewerk en programmeer werk. niet veel meer maar toch wat tijd.

[Verwijderd]

we zijn 100% consequent in de prefixs. maar ikzelf thuis heb ze nooit gebruikt en zal toch een keus moeten maken.

ene kant lijkt het beter. en denk dat ik het doe. maakt de database toch meer overzichtelijker. maar andere kant is het niet het makkelijkste.

[rsmits]

Verwijderd schreef op zondag 09 september 2007 @ 18:22:
in het bedrijf waar ik werk worden deze prefix gebruikt. grote software pakketen phpbb/vbulletin gebruiken het op dezelfde manier. daarom zocht ik raad.

overzichtelijk, dat denk ik ervan. hoe het nu is. maar andere kant is het meer typewerk en programmeer werk. niet veel meer maar toch wat tijd.

De reden die ik kan bedenken waarom phpbb/vbulletin en dergelijke pakketten het gebruiken, is omdat deze opensource zijn en door velen gebruikt worden. Bij bepaalde hosts krijg je maar 1 database toegewezen en is het dus overzichtelijk als je meerdere pakketten (bijvoorbeeld Joomla als CMS en phpbb als forum) in dezelfde database zet.

Als je het systeem voor jezelf houdt en niet met meerdere pakketten ernaast werkt, zijn de prefixes naar mijn mening overbodig.

[Muthas]

Veel verstand heb ik hier niet van, maar waarom een varchar(255) voor username gebruiken als je waarschijnlijk toch een veel lagere maximum lengte hebt. Eveneens voor password wat waarschijnlijk een hash van 32 (of 40) tekens is.

[Verwijderd]

Moet de lengtes nog optimilarseren. had maar eve een voorbeeldje gemaakt.

niks meer. daarom 10/255 als lengtes...

ging mij over de prefixs etc...

PHPBB die heeft een prefix phpbb_users. maar ik heb het hier over kolom namen zoals

user_id
user_username
user_level

of

uid
username
userlvel

goed bekenen is het eerste voorbeeld veel meer overzichetlijker.

[rsmits]

Ik denk dat jij de enige bent die daar wat over kan zeggen, dat is puur wat je zelf makkelijk vind werken. Bij een ID is het handig om de tabelnaam mee te geven, voor de overige kolommen zou ik het persoonlijk niet doen.

De methode die Janoz noemde gebruik ik wel af en toe: tabelnaam.kolom. De tabelnaam heeft in principe alleen toegevoegde waarde bij JOINs, omdat het het overzicht verbeterd.

[Janoz]

Verwijderd schreef op zondag 09 september 2007 @ 20:51:

PHPBB die heeft een prefix phpbb_users. maar ik heb het hier over kolom namen zoals

user_id
user_username
user_level

Dan vraag ik je nogmaals, wat is uberhaupt het nut van de user_ prefix? Waarom niet gewoon username en level (id laat ik even in het midden. Zoals Curry ook al aangeeft zijn daarover de meningen verdeeld. Persoonlijk houd ik de non prefix conditie aan zodat in 1 oogopslag duidelijk te zien is welk veld het ID is en welk veld foreignkeys)