DB dev logic

  1. Ha van egy 'animal' táblád akkor érdemes ilyen oszlopokat csinálni: animal_id, anim_name, anim_weight
  2. Ha használsz egy általános flag oszlopot - 'active' - akkor itt a neve legyen.... hmm: 'a_active';
  3. Ha van egy 'insect' táblád és az 'animal' joinolod egy másik táblában - 'creatures' - akkor ott ez legyen a sor azonosító oszlopnév: 'animal_insect_id', csak hogy tud honnan jöttek az adatok.
  4. Utána érdemes használni az 'a_i' patternt a nevekre - 'a_i_count' - mert az még jobb, kevesebb munka jobb áttekinthetőség.
  5. Ha egy adattípus boolean akkor természetes hogy lehet az értéke null.
  6. Teljesen jó ha sor update helyett kitöröljük a régit és egy újat hozunk létre.
  7. Készíts oszlopokat amiket kurvára senki sem kért, - 'animal -> lofasz_size' - majd írj hozzá függvényt hogy a 'lofasz_size'  is mindenképpen bemenő paraméter legyen - mint null - , mert hátha kellhet majd egyszer.
  8. Egy 30 > kevesebb  sorú SQL lekérdezést sokkal nehezebb karbantartani, mint a 20 ezer soros program kódot.
  9. Ha egy lekérdezés egy paraméterre adatot ad vissza, akkor több paraméterre legyen kedves looopolja kliens a queryt.
  10. Ha lekérdezést adatot ad vissza, mehet rá a pipa, majd kidebugolja más úgy is mi a bánat hordódott össze benne.

Most így hirtelen.

Hozzászólások

Milyen emberekkel vagy te körülvéve? :D

Én a sz@ros érettségimmel full amatőr vérpistiként rájöttem ezekre, szerintem még az első évemben. Mármint hogy ne, sőt, kérj elnézést ha ilyen hülyeségekre gondolsz már akkor is. Már direkt olyan szemmel mentem végig, hogy van-e olyan eset ahol bármelyik a fentiek közül logikus lehet, de nem találok.

Ha nem válaszolnék kommentben, hát küldj privátot!

Az animal_id -nak lehet értelme: ha minden primary key-nek egyedi neve van, akkor működik a natural join. :)

És ha egy táblában minden oszlopot prefixálunk az oszlop nevével, egyes SQL CLI-knél sokkal kényelmesebben működik az autocomplete. (Pl. SQLite minden táblából fel szokta ajánlani az összes oszlopot.)

Nem mentegetem a munkaerőt, csak ötletelek, hogy mire gondolhatott a költő…

int getRandomNumber() { return 4; }  // ← aláírás
//szabályos kockadobással választva. garantáltan véletlenszerű.  xkcd

Nem tudom, hogy milyen sql-ről van szó, de többen is láttam már, főleg ha a keretrendszer úgy akarta, mindenféle auto-join-okat, erre tudok én is csak gondolni, de annak meg a rövidítéses megoldás nem jó, az a->animal nem egyértelmű.

Ha nem válaszolnék kommentben, hát küldj privátot!

Volt egyszer hol nem volt egy adatbázis, az volt a neve, hogy Databases of Orthologous Promoters (DOOP). Még 2003-ban, a doktorálásom előtt dolgoztam rajta, az akkori Mezőgazdasági Biotechnológia Kutatóintézetben (manapság, ha jól értem, a Nemzeti Agrárkutatási és Innovációs Központ része). Szóval egy még korábbi projektemben használtam MySQL-t adatok tárolására és ide-oda tologatására, azért vettek be ebbe is. Az én feladatom az volt, hogy a csapat által kiszámolgatott adatokat tároljam egy dedikált MySQL szerveren, hogy azokat könnyen, gyorsan ki lehessen húzni a további számításokhoz. Én bizony előszeretettel használtam az általad előhozott 1-4 tételt, egyszerűen azért, mert az analízis oldalon a több táblából behúzott ID-kat (és egyéb névazonos mezőket) könnyebb volt így megkülönböztetni a sok száz soros (perl)scriptekben, amikben a további számolások történtek. Legalábbis 'animal_insect_id' biztosan volt az általam elkövetett adatbázisban is. Aztán 2003 végén eljöttem onnan (ledoktoráltam, és kijöttem ide Finnországba, szintén kutatóként), az általam munkaeszköznek legyártott adatbázis meg publikus frontendet kapott és aztán ki tudja, mi lett vele. Cikk is született belőle egy amúgy elég rangos újságban. 

Arról nem volt tudomásom, hogy az adatbázis profik kezébe is került (én biológusként végeztem, aztán migráltam bioinformatikus vonalra), csak remélni tudom, hogy nem a DOOP valamelyik leszármazottja okozta a hasfájásodat, mert akkor bizony én vagyok az egyik elkövető.

Azért mondjuk tök jó lenne, hogy csak úgy a közművelődés kedvéért elmondanád, hogy a fenti pontokkal mi is a probléma, mert a legtöbbjénél nem látom be magamtól (mondjuk van aminél igen). Hadd tanuljunk új dolgokat.

Csaba

Itt igazából akkor van gond, ha az elkövető egy production-ben levő rendszeren dolgozik, és nem szólt még se tanár, se kolléga neki, hogy akkor ezt így ne.

Teljesség igénye nélkül, mert nem én lettem megszólítva:

  1. Ha van egy 'animal' táblád akkor érdemes ilyen oszlopokat csinálni: animal_id, anim_name, anim_weight
    1. brevity már nem szükséges, de azért eszetlenül sem érdemes animal.animal_id-t írni, van mondjuk "SELECT animal.id AS "animal_id" ..." ha egyszerű megoldás kell (MySQL-ben), és akkor az id az maradhat generikus, lehet pl. módosítást-törlést-kijelölést minden id-t tartalmazó oszlopnál automatizálni, generálni a kódot, ... hirtelen ezek jutnak eszembe.
  2. Ha használsz egy általános flag oszlopot - 'active' - akkor itt a neve legyen.... hmm: 'a_active';
    1. ugyan az mint az előző, csak még a kolléga is rámutatott, hogy általános oszlop, ergo több helyen is működhetne ugyan az a kód, erre csak különbség lett téve az azonos funkciójú adat különböző példányai között
  3. Ha van egy 'insect' táblád és az 'animal' joinolod egy másik táblában - 'creatures' - akkor ott ez legyen a sor azonosító oszlopnév: 'animal_insect_id', csak hogy tud honnan jöttek az adatok.
    1. ez már kicsit nehezebb, mert itt már az is kérdéses, hogy ha join-olsz, és ilyen rosszul néz ki, akkor lehet a struktúrát se ártana újragondolni, az insect is animal, ..., de valójában ez is "csak legyen egyszerűen id", és máshol hivatkozzd be, hogy az miért, milyen join eredménye. De látni kéne a struktúrát.
  4. Utána érdemes használni az 'a_i' patternt a nevekre - 'a_i_count' - mert az még jobb, kevesebb munka jobb áttekinthetőség.
    1. itt meg túl sok a brevity, az hogy "a" az animal is lehet, de action, akármi más, az "a_i_count" nem beszédesebb, mint a "count", semmit nem nyertél (csak mondjuk az automata sum függvényed nem ismeri fel a count oszlopot, mint generikus típust)
  5. Ha egy adattípus boolean akkor természetes hogy lehet az értéke null.
    1. oké ez csak egyszerűen nem érti, hogy mire való az allow null, hibalehetőség, boolean az true-false, ne is legyen lehetőség rögzíteni az adatbázisba más értéket
  6. Teljesen jó ha sor update helyett kitöröljük a régit és egy újat hozunk létre.
    1. remélem tranzakció nélkül, hátha az egyik parancs elhasal, de legalább használjon közben table level lock-ot is, hadd akadjon meg az egész - atomizálás egy nagyon érdekes téma, érdemes beleásni magát az embernek, best practices témában ez kb. az első nagy kérdéskör
  7. Készíts oszlopokat amiket kurvára senki sem kért, - 'animal -> lofasz_size' - majd írj hozzá függvényt hogy a 'lofasz_size'  is mindenképpen bemenő paraméter legyen - mint null - , mert hátha kellhet majd egyszer.
    1. kód átláthatósága, nem kell jövőállónak lenni úgy, hogy azt a jövőben is be lehessen rakni 2 perc alatt :), valaki leütésszámra, vagy commit-okra kapta a fizetést, vagy csak dolgoznia kellett valamit, és nem tudta mit
  8. Egy 30 > kevesebb  sorú SQL lekérdezést sokkal nehezebb karbantartani, mint a 20 ezer soros program kódot.
    1. spagetti kód? sql a php programkódban, minden helyen megismételve, nem kiszervezve function-be?
  9. Ha egy lekérdezés egy paraméterre adatot ad vissza, akkor több paraméterre legyen kedves looopolja kliens a queryt.
    1. terméklistázásnál láttam már olyant, hogy nem az első 20 tételt kérte le a kedves kollega, hanem egyesével a 20-at, mert nem volt megírva a limit-et kezelő function, egyszerűen id alapon 1 termék adatait lehetett lekérni
  10. Ha lekérdezést adatot ad vissza, mehet rá a pipa, majd kidebugolja más úgy is mi a bánat hordódott össze benne.
    1. ehhez is több info kéne, de sokan nem foglalkoznak azzal, hogy ami visszajön adat az ránézésre legalább helyes? Termék neve helyére így kerül a mysql hibakód (nem vicc, láttam élesben), ára helyére a hibaüzenet. Vagy a neve helyére a szöveg és ID volt a kód, ezért még jól is nézett ki? :)

Ha nem válaszolnék kommentben, hát küldj privátot!