[mySQL] namen van velden

[hobbit_be]

Ben bezig met een "intelligent" database systeem met PHP en mySQL.

intelligent wil zeggen dat de applicatie weet wat elk veld is (ie een "email", "url" , etc), dat ie kan cascaden (up, del), en natuurlijke alle foreign keys, link tables voor me maakt en onderhoud. Op zich geen probleem want heb ik al gedaan in java/ojb.

Het is echter een simpelere vraag:

Om het allemaal wat sneller te houden definieer ik voor elk veld al ineens wat basis info zodat het systeem niet constant hoeft te weten wat elk ding nou is.

eg: table campaigns heeft

cnID
ctName
cdTime als veldnamen.

waarvan "c" voor campaign staat (zodat mijn joins niet steeds AS nodig hebben) en de volgende character het basis type definieert: n == number, t == text, d== Date.

die worden dan weer gebruikt voor insert/update handing bij het creeren van de SQL (met '' of zonder je kent dat wel).

maar nu begint het wat groot te worden (meer dan 26 tables en wou ik dus overstappen naar:

n_campaigns_id
t_campaigns_name

etc. ook niets mis mee behalve dat er blijkbaar een maxiumum van 32 chars kunnen zijn met mySQL. ook telkens een "explode" doen lijkt me weer wat overkill.

allemaal eigenlijk omdat

SELECT * FROM campaigns niet campaigns.id, campaigns.name teruggeeft als columnnames. (weet niet of dat standaard is of niet in SQL btw).

dus dit is een open vraag: hoe noemen jullie je veldnamen, en jullie concepten erachter?.

[RedRose]

Ik gebruik meestal camelstyle-namen, dus bijvoorbeeld: campaignID in jouw geval. Verder zet ik eigenlijk alleen een 'trefwoord' als 'campaign' voor primairy keys, foreign keys of velden die ook in andere tabellen met gelijkende veldennamen staan en die in één query tegelijk gebruikt worden. Daarnaast gebruik ik sowieso bijna nooit een SELECT * - statement, juist om de duidelijkheid te bewaren .

Maar wat de standaard is, geen idee.

[Verwijderd]

Voor bijv campaigns id => cmpg_id
gewoon de eerste 4 medeklinkers van het woord gebruiken (of als het er minder zijn, alle medeklinkers).

user => usr
newsitems => nwst
customer => cstm
etc. etc.

[drm]

* drm gebruikt liever gewoon wel aliases (AS) als dat nodig is.

Die prefixes leveren alleen maar heel veel ergernis op wanneer je ze niet nodig hebt...

[ Voor 3% gewijzigd door drm op 17-12-2003 17:06 ]

[Verwijderd]

drm schreef op 17 december 2003 @ 17:05:
* drm gebruikt liever gewoon wel aliases (AS) als dat nodig is.

Die prefixes leveren alleen maar heel veel ergernis op wanneer je ze niet nodig hebt...

Ben ik het niet 100% mee eens. Die prefixes zorgen er veelal voor dat je in 1 oogopslag ziet van welke tabel je de velden aanspreekt. Zeker bij grote ingewikkelde queries erg gemakkelijk. Hou je (tenminste ik wel) een beetje overzicht.

Anders moet ik weer na gaan denken welke alias ik ga gebruiken of gebruikt heb

[drm]

In jouw voorbeeld heb je ze dus wel nodig, omdat het anders onduidelijk wordt

Even wat suffe voorbeeldjes van wat ik bedoel:

code:

SELECT
   name,
   product_id
FROM
   product

Geen aliases nodig

code:

SELECT
   product_category.name category_name,
   product.name          product_name,
   product.product_id
FROM
   product_category 
   LEFT JOIN product USING(
      product_category_id
   )
ORDER BY
   category_name

Heb je ze dus wel nodig

De enige uitzondering die ik maak zijn primary en foreign keys. Die geef ik doorgaans gewoon de naam van de tabel met _id er achter, zodat ik zoveel mogelijk gebruik kan maken van USING ipv ON.

[hobbit_be]

hmm ik vermoede al dat het niet 'cleancut' ging zijn.

ik snap drm's standpunt van die using en zo clean mogelijk houden best wel. maar dit lijkt me meer aangeraden voor delen waar er meer manueel gewerkt word. maar zoals hij zelf aanhaalt heeft hij dus tamelijk vaak een "AS" nodig met velden met zelfde naam. behalve dan de key. vraag ik af of je daar dan het 'using' voordeel mee 'verantwoord'.

Ik ben eerlijk gezegt al een beetje verbijsterd dat een paar van jullie ook per veld de tablenaam (op welke manier dan ook) erin zetten.

tja in zo'n link table wordt het al snel:

code:

group_user_link
     n_gul_id
     n_gul_grp_id
     n_gul_usr_id
user
     n_usr_id
     t_usr_name
group
     n_grp_id
     t_grp_name

echt mooi is het niet maar wel 100% consistent (en dat heb ik liever) zeker als ik
mijn queries als volg schrijf

"user[?]/groups(name)"

maar over het feit van die type declaration geen feedback - is dit 'not' done of een beetje te proggerig? het heeft me al heel vaak enorm geholpen omdat het een beetje 'strong' typing duidelijk maakt.

bedankt alvast voor de feedback .

[TheRookie]

ik zou de typering van de column als laaste neerzetten.

Dus gul_id_n, i.p.v. n_gul_id;

gul_id (de daadwerkelijke naam) is denk ik belangrijker dan het type ...

lijkt me trouwens dat een ID altijd numeric is/zou moeten zijn

[ Voor 19% gewijzigd door TheRookie op 17-12-2003 21:33 ]

[hobbit_be]

the rookie:

idd id is altijd numeriek, maar ik hou het graag consistent he

hmm vanachter zetten is ook wel mooi (very "actionscript" en anti-hungarian ). maar voor me insert/update routines kunnen zo heel snel werken ie (eerste char == n dan zet je geen '' anders d...) nu moet ie eerst nog gaan exploden op een per field basis wat misschien wat trager is. maar idd wel cleaner.

[Erkens]

TheRookie schreef op 17 december 2003 @ 21:32:
lijkt me trouwens dat een ID altijd numeric is/zou moeten zijn

hoeft niet
een ID is een identifier, het identificeert dus 'iets' en of je dat nu met een nummertje doet of een tekenreeks maakt niet uit
zo heb ik ergens een tabel met een char(32) als primairy key en die noem ik session_id

[pistole]

Ook nog even een € in het zakje :-)

Wat betreft naamgeving van velden: consequent hetzelfde stramien gebruiken vind ik het belangrijkste. Om nu in je velden je tabel naam terug te laten komen, vind ik persoonlijk overdreven (gebruik idd aliases; zie hieronder)

Aliasen gebruiken: gebruik juist wel aliasen in de vorm van [tabel].[kolom], zeker als je je SQL queries genereert. Dit houdt alles overzichtelijk en niet-ambigu (wat is het tegenovergestelde van ambigu ookalweer? Ohja eenduidig) Helemaal als je je code genereert, want dan vervalt het "intyp-argument

Misschien nog een tipje voor tabellen die een n:n relatie ondersteunen: ik gebruik hiervoor altijd l_<tabel1>_<tabel2> voor; in de relatie tabel gebruik ik alleen de PK's uit de genoemde tabellen. Dit is dmv scriptjes altijd weer automagisch te queriëen zolang je je houdt aan je veld naamgeving.

[ Voor 6% gewijzigd door pistole op 17-12-2003 21:57 ]

[JaQ]

ik probeer me altijd aan de Oracle standaard te houden. (maar ik werk dan ook meer met Oracle dan met MySql) Deze standaard is goed, tot overdreven, gedocumenteerd. zoek met google.

De standaard is gebaseerd op lettergrepen en woorden. Soms voel je je dus net een kleuter die woorden zit op te hakken, maar uiteindelijk heb je wel altijd unieke tabel en kolomnamen, zijn primary, foreign en unique keys goed af te leiden uit kolomnamen etc.

[RedRose]

hobbit_be schreef op 17 december 2003 @ 18:08:
maar over het feit van die type declaration geen feedback - is dit 'not' done of een beetje te proggerig? het heeft me al heel vaak enorm geholpen omdat het een beetje 'strong' typing duidelijk maakt.

bedankt alvast voor de feedback .

Nou ja, sinds ik ook in C/C++ programmeer begrijp ik het waarom van strong typing veel meer. PHP-ers snappen dat doorgaans helemaal niet.

Maar ik vind data die je uit welke database dan ook haalt een datatype. Dat elk veld dan zijn eigen type heeft, dat wordt pas belangrijk als je er in je progammeertaal variables of objects van maakt en er een operatie in de taal zelf op moet uitvoeren.

Als het jou helpt duidelijkheid te bewaren, dan zou ik dat gewoon blijven doen. Ik vind het zelf niet nodig, maar ik ben ook maar een PHP-progger.

[drm]

hobbit_be:
ik snap drm's standpunt van die using en zo clean mogelijk houden best wel. maar dit lijkt me meer aangeraden voor delen waar er meer manueel gewerkt word. maar zoals hij zelf aanhaalt heeft hij dus tamelijk vaak een "AS" nodig met velden met zelfde naam. behalve dan de key. vraag ik af of je daar dan het 'using' voordeel mee 'verantwoord'.

Wellicht niet, maar over het algemeen wegen de aliases niet echt op tegen het aantal joins wat uitgevoerd moet worden (in mijn geval). Meestal gaat het gewoon om "selecteer een aantal producten uit die en die taal die voorkomen in die en die categorie". Dan selecteer ik uiteindelijk toch alleen de naam en evt. een plaatje van het product, maar moet ik toch gauw 3 joins uitvoeren.... Ik weet 't dan wel, hoor

Overigens gebruik ik (tegenwoordig) voor link tables meestal een $ om de link aan te geven. Mensen hier zullen het wel ranzig vinden, maar ik vind het toch het duidelijkst. Bijvoorbeeld een link tussen product en product category wordt dus product$product_category.

Dat afkorten van veld- en tabelnamen vind ik dus echt helemaal niks. Ik wil dat een database zichtzelf zo veel mogelijk uitlegt, niet dat ik me nog eens af moet gaan vragen waar grflplpmrsnm_id nou eigenlijk voor staat... Ik heb dat nooit begrepen, dingen als "artnr" en "desc" enzo, schrijf 't gewoon voluit, staat veel netter.

Maar uiteindelijk denk ik toch dat het een kwestie van smaak is