ugrás a tartalomhoz

ORM?

kemmma · 2012. Már. 28. (Sze), 19.45
Elmúlt időszakban egyre többször volt téma itt különféle keretrendszerek, ennek kapcsán merült fel benne, hogy rákérdezzek az ORM-re! Mikor, miért kell használni? Én is barátkozom mindenféle keretrendszerrel, és tulajdonképpen hasznosnak is találom, de valahogy az adatbázisok ezen fajta megközelítése teljesen idegen. Nem tudom elhelyezni.

Ne azt írjátok, hogy biztonságosabb, mert nekem ekkora szemléletváltáshoz ez elsőre kevésnek tűnik. :) És biztos van ennél jobb érv is. :)

(bár, ha valaki megkérdezné, hogy egyáltalán tudom-e, hogy mi az az ORM, akkor nem biztos, hogy tudnék rá határozott választ adni. Objektum-relációs térképezés:)
‹ SwiftMailer --> GMAIL Generált thumbnail fotó letöltő link ›
 ■
1

A relációs adatbázisban

inf · 2012. Már. 28. (Sze), 19.57
A relációs adatbázisban rekordok vannak az ORM meg objektumokat ad vissza neked. Ennyi a lényege. Extra szolgáltatás szokott lenni ehhez, hogy generáltatják az SQL-t, és emiatt könnyű átállni egyik adatbázis típusról egy másikra, illetve így a kéréseket is meg tudod adni objektumok formájában, nem kell SQL-t írnod (legalábbis az esetek nagy részében). Egy egyszerű ORM-et megírni egyébként nem egy bonyolult dolog. Kell egy transzformáció, ami objektum gráfból rekordokat csinál, meg ugyanez visszafele, utána meg kell egy SQL generáló rész, ami a rekordokból SQL-t csinál.
2

emiatt könnyű átállni egyik

nova76 · 2012. Már. 28. (Sze), 20.50
emiatt könnyű átállni egyik adatbázis típusról egy másikra

Azért a könnyűt azt felejtsük. Általában ami PHP, az többnyire MySQL. Elég nehéz leképezni mondjuk a Firebird SQL-t és a MySQL-t egy ugyanolyan objektummal. Ha pedig valami istentelen feltételt akarsz beletenni, akkor aztán tényleg nem fog menni. És általában az a legnagyobb baj, hogy olyan helyeken ugrik elő a hiba, amire nincs unit teszt, nincs semmi az égvilágon, mert gyorsan és kapkodva csinálta, aki csinálta. Vegyük mondjuk a Dcctrinet, ami ügye nem tud lekezelni egy vagy kapcsolatot a feltételben, kézzel írhatod bele. Innentől kezdve írhatnál sql-t is. Vagy vegyük a Propelt, ami ugyan tudja, de vért pisilsz mire összehozol egy ütősebb lekérdezést.

Én azért használom, mert a kód átláthatóbb tőle. Például ha van egy webshop kosaram, akkor akár végig literálhatok a $kosar->Termekek tartalmán. Most oda biggyesztenék be egy sql utasítást?
3

Azért a könnyűt azt

inf · 2012. Már. 28. (Sze), 21.18
Azért a könnyűt azt felejtsük. Általában ami PHP, az többnyire MySQL. Elég nehéz leképezni mondjuk a Firebird SQL-t és a MySQL-t egy ugyanolyan objektummal.

Hát egy ugyanolyan objektummal tényleg nehéz... XD
4

Mind a Doctrine 1, mind a

szjanihu · 2012. Már. 28. (Sze), 21.23
Mind a Doctrine 1, mind a Doctrine 2 kezeli a "vagy" kapcsolatot. Egyébként meg PostgreSql-lel is rengetegszer használtam az előbbit, gond talán csak a pessimistic locknál volt.

Leképezni egy ugyanolyan objektummal meg egyáltalán nem nehéz, ezért vannak az ORM-ek.

Finoman fogalmazok, ezért csak annyit mondok, hogy nagy butaságokat írsz.
5

Mind a Doctrine 1, mind a

nova76 · 2012. Már. 29. (Cs), 08.19
Mind a Doctrine 1, mind a Doctrine 2 kezeli a "vagy" kapcsolatot.

Példa. Mondjuk legyen ez a feltétel:
((deleted is null) or (finished is not null)) and ((name ='okosvagyok') or (name ='nemvagyokokos'))
Ezt le tudod írni propelben sql nélkül. Docrineban hogyan?

Leképezni egy ugyanolyan objektummal meg egyáltalán nem nehéz, ezért vannak az ORM-ek.

Annyira nem nehéz hogy se a Doctrine se a Propel nem működik mondjuk Firebirddel. Ha meg már próbáltál mysql-ről oracle alá átteni egy nagyobb projektet, akkor a könnyűről lenne tapasztalatod.
6

MySQL->Oracle

H.Z. v2 · 2012. Már. 29. (Cs), 09.05
Jól sejtem, hogy ez már részben a performanciáról, részben az Oracle nagyobb tudásáról szólt? És azt, hogy nem volt mentes az eredeti kód sem az SQL-ektől?

Nem győzöm hangsúlyozni, hogy igencsak felszínesek az ismereteim, de amit eddig láttam ORM címén, abból nekem az jött le, hogy
- amíg meg lehet oldani a dolgot SQL nélkül, addig nagyon meg tudja könnyíteni az ember munkáját egy ilyen rendszer, főként amikor egyik RDBMS-ről a másikra kell átállni vele.
- ugyanakkor performancia terén... hát finoman fogalmazva macerássá teszi az optimalizálással küzdő szakember életét.
------
Amúgy Doctrine kapcsán valami ilyesmire gondoltál? (Csak rákerestem a "doctrine complex sql query" kifejezésre)
7

Kb. úgy, ahogy te írtad. DQL:

szjanihu · 2012. Már. 29. (Cs), 09.47
Kb. úgy, ahogy te írtad. DQL: http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/dql-doctrine-query-language.html

A Doctrine 1 elvileg kezelte a Firebird-öt, bár erre sose volt szükségem.
9

Elvileg. Elvileg az 1.2 is.

nova76 · 2012. Már. 29. (Cs), 21.20
Elvileg. Elvileg az 1.2 is. De ahogy a puding próbája az evés... Amúgy lehet még szükséged rá, elég sok delphi+FB kód létezik és nagyon jó kis adatbázis. Ráadásul minden tekintetben ingyenes, ellenben mondjuk a mysqllel.

Én valami ilyesmire gondoltam (Propel):
http://www.techiecorner.com/146/symfony-how-to-query-using-criteria-or/
Ez a sztringként összerakott feltétel nem túl OOP-s.
10

Ez a sztringként összerakott

Poetro · 2012. Már. 29. (Cs), 21.21
Ez a sztringként összerakott feltétel nem túl OOP-s.

Ráadásul mivel stringként adod meg az utasítást, ezért már nem is lehetsz adatbázis független.
11

Ezt nem teljesen értem.

szaky · 2012. Már. 30. (P), 15.47
Ezt nem teljesen értem. Miért?
24

A firebird-öt a Doctrine 1

szjanihu · 2012. Ápr. 1. (V), 11.24
A firebird-öt a Doctrine 1 támogatta, a 2 már nem. Gyakorlatilag is támogatta, csak nincs vele tapasztalatom.

A DQL a Doctrine Query Language-nek a rövidítése. A Doctrine 2-ben már egy környezetfüggetlen nyelvtan van definiálva, ami a DQL-t generálja. A DQL adatbázis független.

Az, hogy te közvetlenül írod meg a DQL-t, vagy QueryBuilder objectet csinálsz, ami végül szintén DQL-t ad vissza, irreleváns.

Az általad linkelthez hasonló megoldás Doctrine 2-ben.

(A válasz egy része nova76-nek címezve)
8

példák

lacy · 2012. Már. 29. (Cs), 16.15
Szia! Írok két egyszerű példát. Ajánlom Neked a Symfony keretrendszert, Doctrine ORM-el. Én is idegenkedtem a keretrendszerektől, inkább feltaláltam magamnak a szögletes kereket. Az alábbi példák szerintem megkönnyítik az életet.

// kódból létrehozok egy felhasználót. hol itt az insert into?
$user = new User();
$user->name = "Laci";
$user->email = "...";
$user->save(); // ezután már bent van az adatbázisban az új felhasználó
$user->delete(); // már nincs :)

{
// sémában definiálod, hogy a user_photo táblában a user_id mező az a user tábla id-jével azonos (megadod a relációt a két tábla között). létrehozza neked azokat a metódusokat, amellyel le tudod kérni a relációkat egymásból
foreach($user->getPhotos() as $photo) {
  echo $photo->filename."<br />";
}
12

Én inkább a DTO-k híve vagyok

inf · 2012. Már. 30. (P), 15.55
Én inkább a DTO-k híve vagyok az összes SQL kérést meg kiszerveztem statement objectekbe. Jobb így, mert a statement objectek cseréjével ugyanazzal az interface-el lehet generáltatni a kéréseket bármelyik adatbázis típushoz.
13

Csere

Hidvégi Gábor · 2012. Már. 30. (P), 16.03
Milyen sűrűn szoktál egy rendszer alatt adatbázistípust cserélni?
14

Haha nem sűrűn hálistennek,

inf · 2012. Már. 30. (P), 16.19
Haha nem sűrűn hálistennek, csak az elméletével ismerkedem.
15

Nagyon ritka

Hidvégi Gábor · 2012. Már. 30. (P), 17.34
Korábban már kérdeztem itt a fórumon, és egyedül H.Z. v2 kollega mondta, hogy az utóbbi tíz évben egyszer látott olyan esetet, amikor adatbázisrendszert kellett cserélni.
16

És már én sem emlékszem rá...

H.Z. v2 · 2012. Már. 30. (P), 17.51
És már én sem emlékszem rá... :)
(na jó, ez részben poén, de gondolkodnom kellett, hogy mi is volt az :( )
Ettől függetlenül: ha nem kell nagyon performanciára kihegyezni egy alkalmazást, akkor érdemes úgy megírni, hogy lehetőleg könnyen lehessen adatbázist cserélni alatta. Pusztán azért mondom, mert ahogy változik mostanság a világ, pl. ki tudja, mi lesz a MySQL-lel, amire általában fejlesztenek. (eleve olyan a licence, hogy... szóval olyan... ;) ) és Oracle-ből kinézek valami hasonló húzást, mint amit tegnap olvastam az Adobe-ról a flash kapcsán (utólag pénzt akarnak a flash alapú játékok üzemeltetőinek egy részétől)
De mást ne mondjak: kisebb alkalmazásoknak elég lehet pl. a sqlite, jó ha könnyű róla mysql-re v. postgresql-re váltani.
17

MySQL licenc

Hidvégi Gábor · 2012. Már. 30. (P), 17.58
Pont tegnap este kerestem rá a MySQL licencére, de számomra egyáltalán nem egyértelmű, hogy mikor kell fizetni érte, ráadásul a neten is mindenfélét írnak róla. Tud erről valaki valamit?
18

nyílt forráskód

nova76 · 2012. Már. 30. (P), 18.24
Én úgy tudom hogy nyílt forráskóddal használható. Tehát ha készítesz egy PHP programot, akkor az eleve nyílt forráskódú és ügye át is adod, így ahhoz használhatod. Ugyanezt mondjuk delphi esetében akkor ha a forráskódot is odaadod. Nálam inkább a kérdés az, hogy mi van akkor ha PHP, de a forráskódot nem adod ki. Például írsz egy szolgáltatást PHP-ban, akkor mi van?
19

Szerintem kevered...

H.Z. v2 · 2012. Már. 30. (P), 18.31
... a nyílt forrást a scripttel.
A nyílt forrás azt jelenti, hogy bárki hozzáférhet a forrásához.
A PHP forrását meg rajtad kívül max. a szolgáltatód rendszergazdája láthatja.
Viszont az pl. érdekes kérdés (számomra, de én nem olvastam még el a licenc feltételeket), hogy ha egy szolgáltatónál használsz mysql-t, akkor annak a díját ki fizeti?
20

Akkor nem kell érte fizetni,

Hidvégi Gábor · 2012. Már. 30. (P), 19.06
Ha a szolgáltató GPL-szerű licenccel rendelkező szoftvereket (Apache, PHP) bocsájt a rendelkezésedre, akkor nem kell fizetnie.
21

OK, ő nem fizet. De én

H.Z. v2 · 2012. Már. 30. (P), 19.25
OK, ő nem fizet. De én használhatom-e jogosan, anélkül, hogy fizetnék a jogtulajdonosnak (Oracle?).
Hiszen én egy végsősoron zártkódú szoftvert futtatnék a szolgáltatómnál. :)
22

Akkor először mégiscsak jól

Hidvégi Gábor · 2012. Már. 30. (P), 19.38
Akkor először mégiscsak jól értettem : ) Neked nem kell fizetned, mert te egy webes szolgáltatást adsz el, azaz a MySQL-t csak közvetetten használják az ügyfeleid.
23

A kérdés inkább az, hogy ki

inf · 2012. Már. 30. (P), 21.48
A kérdés inkább az, hogy ki ellenőrzi, hogy fizetsz e. Jelen esetben senki, tehát nem kell fizetni. Legalábbis ebben az országban így működnek a dolgok...
25

nagyon jó kérdés

_subi_ · 2012. Ápr. 1. (V), 18.41
Nagyon jó kérdés, engem is érdekelne. Továbbolvasva a szálat, sem látok egyértelmű választ.
26

Utánajárok, és majd egy új

Hidvégi Gábor · 2012. Ápr. 2. (H), 08.42
Utánajárok, és majd egy új fórumban megosztom a válaszokat.