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:
- Ha van egy 'animal' táblád akkor érdemes ilyen oszlopokat csinálni: animal_id, anim_name, anim_weight
- 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.
- Ha használsz egy általános flag oszlopot - 'active' - akkor itt a neve legyen.... hmm: 'a_active';
- 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
- 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.
- 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.
- 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.
- 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)
- Ha egy adattípus boolean akkor természetes hogy lehet az értéke null.
- 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
- Teljesen jó ha sor update helyett kitöröljük a régit és egy újat hozunk létre.
- 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
- 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.
- 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
- Egy 30 > kevesebb sorú SQL lekérdezést sokkal nehezebb karbantartani, mint a 20 ezer soros program kódot.
- spagetti kód? sql a php programkódban, minden helyen megismételve, nem kiszervezve function-be?
- Ha egy lekérdezés egy paraméterre adatot ad vissza, akkor több paraméterre legyen kedves looopolja kliens a queryt.
- 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
- 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.
- 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? :)