Új hozzászólás Aktív témák

• #2097 martonx veterán modder #2095

  Új Válasz 2014-01-27 17:39:03 #2097

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  martonx

  veterán

  válasz modder #2095 üzenetére

  - az egyik, amiből az egész kiindult, hogy ha a lekérdezéseket szerkesztem valamilyen kliens programban, akkor jobban esik az agyamnak, ha a konkrét információt látom a mezőben, ha ellenőrzöm, jó lekérdezést írtam-e meg. Ide tartozik még, ha valaki (vagy én) évek múlva hozzá akar nyúlni a szoftverhez és adatbázishoz, leegyszerűsödik a dolga.
  Ez evidens, de ha ez így lenne, akkor mindjárt eljutunk oda is, hogy minek relációs adatbázist használni. Ennyi erővel eltárolod egy text file-ban az egészet, és nincs is miről beszélnünk.

  - a városos példánál maradva nincsen szükség joinra, ami egy kicsit le tudja egyszerűsíteni a lekérdezést, ha egyébként az nagyon összetett; sok másik jointot is tartalmaz.
  Erre lennének valóak a view-k, tárolt eljárások.

  - ha szoftverben valamilyen ORM frameworkot használunk, közvetlenül benne lehet a város neve a személyek entitásban, ahelyett, hogy egy varos entitason keresztül kéne hozzáférnem az értékhez. (Elképzelhető, hogy egy-egy kapcsolatnál be lehet süllyeszteni a személy entitásba a várost, de most nem jut eszembe, hogy pl. JPA-nál lehet-e)
  Hogy jön ide az ORM? Olyan view-t, vagy selectet, vagy tárolt eljárást írsz, amilyet akarsz, és az lesz benne, amit akarsz. Végül az ORM-et arra húzod rá, amire jólesik (legalábbis NHibernate, Entity Framework-ös tapasztalataim alapján).

  Szerintem maga a kérdés feltevés értelmetlen volt, hiszen ha ilyen bagatell a dolog a részedről, ilyen pici a projekt, ilyen minimális adattal, meg különben is ennyire értesz hozzá, akkor minek kérdezted meg? Úgy kókányolsz vele, ahogy akarsz. Ha viszont igényes munkára törekszel, akkor meg miért nem fogadod meg a tanácsokat?

• #2096 fordfairlane veterán modder #2095

  Új Válasz 2014-01-27 17:09:35 #2096

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz modder #2095 üzenetére

  Egyébként én először olyan információt akartam szövegként tárolni, ami tipikusan egy enum (SQL) típus lenne, és a mező "kardinalitása" olyan 10 db érték körül mozog. Enummal az a baj, hogy nem elég dinamikus, ha új értékre van szükségem az alkalmazásban, akkor módosítanom kell az elérhető enumok listáját, ami MySQLnél azt is eredményezheti, hogy újragenerálja az egész táblát. És az enumra lett volna alternatíva a numerikus vagy szöveges érték, ahol én arra szavaznék, hogy legyen csak szöveges pl.
  Státusz = {"active", "inactive", "suspended", "deleted"} ahelyett, hogy 1,2,3,4-t tennénk a mezőbe. És szerintem ez tényleg nem nagy eretnekség.

  Már miért lenne eretnekség, sehol nincs előírva, hogy felsorolás mezőnek INT-nek kell lennie. Enum mehet a fix készletnek, CONSTRAIN-es kapcstábla a variábilis jellegűnek. Felindexelve egy varchar is gyors, és csak emiatt fölösleges egy plusz INT-re absztrakciót beemelni a táblaszerkezetbe.

Új hozzászólás Aktív témák