Můžete reprezentaci objektu aplikace takovým způsobem, že relační databáze může pochopit?

hlasů
2

Bill Karwin má blogu s názvem „ Proč byste měli použít ORM ?“ která je projednávána na Reddit a já jsem zmatená o několik bodů.

V něm říká v komentáři části:

OODBMS a ORM funguje pouze na objekty, které jsme instancí v aplikaci aplikační vrstvě. Tedy neexistuje žádný způsob, jak dělat dotaz takto:

UPDATE Bugs SET status = 'uzavřená' WHERE status = 'OPEN';

Chcete-li to v ORM nebo OODBMS, měli byste načíst všechny chyby, které odpovídají kritériím a konkretizovat objekty pro ně. Pak můžete nastavit atribut a uložit předměty zpět do databáze jeden po druhém. To je drahé a rozhodně vyžaduje více kódu než ekvivalentní operaci SQL uvedeno výše.

To ilustruje výhodu jazyk jako SQL, který zachází sady jako datový typ prvotřídní. OO paradigmatu nemůže nahradit relační paradigma ve všech případech. Tam jsou některé běžné operace, které SQL může udělat mnohem lépe.

tučný jsem tu část, kde se říká, že budete muset konkretizovat objekty pro tyto chyby při použití ORM, protože to je ta část, že jsem zmatený.

Moje otázka je, proč jste to? Dobře, objektově orientovaný je jedna věc a relační je jiný. Ale je to skutečně pravda, že jsou natolik odlišné, že neexistuje žádný způsob, jak reprezentovat objekt tak, aby mohl být chápán v relační databázi? Například jsem přemýšlel o tom, jak můžete serializaci objektu a pak se dostane zapsat do formátu souboru, skladný. Nemohl byste použít formát takového přenést objekt do relační databáze?

Položena 26/08/2009 v 23:07
zdroj uživatelem
V jiných jazycích...                            


3 odpovědí

hlasů
3

Je [zde] žádný způsob, jak reprezentovat objekt tak, aby mohl být chápán v relační databázi?

Že jste vynechal bod mých prohlášení. Nemyslel jsem, že jeden nemohl uložit objekt v relační databázi. Myslel jsem, že OO paradigmatu předpokládá, že máte instanci tohoto objektu v aplikačním prostoru . To znamená, že můžete volat metody a vlastnosti přístupu k objektu:

$bug->status = 'CLOSED';
$bug->save();

Ale v každém ORM jsem viděl * , nemůžete pracovat na instanci objektu, aniž by nejprve načítání z databáze. Stejně tak můžete ovládat na celých sad řádků v době, jak můžete s SQL.

Bylo by zajímavé vidět ORM balíček, který měl mapování typ objektu do sady dat. Pak, když změníte atribut, to platí pro všechny řádky v tomto setu. Neviděl jsem žádný pokus o ORM, jak toho dosáhnout.

Bylo by velmi obtížné, protože problémů souběžnosti. Má set obsahovat řádky, které byly v tomto setu, když instance objektu, nebo pokud provést změnu, nebo při uložení změn? Pokud to podporuje všechny tyto obměny jsou možnosti, pak to začíná být tak složité, použít ten, kdo by mohl oprávněně myslet, že to nepředstavuje žádné skutečné zlepšení ve srovnání s pomocí SQL přímo.

Re svůj komentář: Není to tak, že nastaví a objekty jsou nekompatibilní. Sada může být objekt (Java má dokonce i kurzy pro sběr a Set). Ale OO paradigmatu předpokládá operace platí pro jednu instanci objektu, zatímco relační operátory se vždy vztahují k souborům (soubor jednoho řádku je stále nastavena). A ve skutečnosti, ORM balíčky, které existují dnes, aby stejný předpoklad, že člověk může změnit pouze jednu instanci řadě v době, a musíte mít přinesl tento řádek před jej můžete změnit.

Je to možná teoreticky rozšířit možnosti ORM pracovat na souborech - ale pokud vím nikdo se snažil, jak to udělat. Můj požadavek je, že ORM, které by mohly dělat všechno , co relační operátory lze udělat, by bylo mnohem horší než použití SQL.

* Jsem s výjimkou SQL-like pseudolanguages jako HQL, které se dějí být součástí balíčku ORM (Hibernate v případě HQL), ale to samo o sobě pseudolanguage nekvalifikuje jako ORM.

Odpovězeno 26/08/2009 v 23:18
zdroj uživatelem

hlasů
1

Základním účelem ORM je pro převod dat z jednoho do druhého reprezentace; tón svými citovat je, že SQL je vhodnější pro dávkové práce, což je pravda - protože ORM by převést tabulek relačních dat do objektu grafy pak zpátky do tabulky.

A (velmi volné) analogie má sudu buničiny, který chcete obarvit červenou. V případě, že DPH představuje SQL databázi, kterou právě skládka barvivo dovnitř a dát mu rozruch. Použití ORM by bylo jako převádění vlákniny na papír, umírající na jednotlivé listy, a pak re-rozvlákňování (nyní barevný) papír vložte zpět do sudu.

Odpovězeno 26/08/2009 v 23:15
zdroj uživatelem

hlasů
1

ORM je mapovat stav objektů na srovnatelném stavu v databázi. Takže, chcete-li změnit stav něčeho v databázi s použitím ORM , jediný mechanismus který máte k dispozici, aby vám je nejprve manipulovat s předměty zastoupené v databázi, a pak uložit jejich stav.

Nejsem si jistý, co máte na mysli:

Přemýšlím o tom, jak můžete serializaci objektu a pak se dostane zapsat do formátu souboru, skladný. Nemohl byste použít formát takového přenést objekt do relační databáze?

Máte na mysli serializaci objektu do struktury, kterou by v zásadě uložit v obytném souboru (např formátu XML) a potom uložit data v databázi? Pokud ano, ano, mohl. Výzvou bude, když chcete hledat pro tuto informaci. Řekněme, že jste chtěli najít všechny „zavřeno“ chyby, měli byste si přečíst každý bug, rekonstruovat ho a zkoumat je to stav, aby zjistil, zda by měly být zařazeny do seznamu.

Odpovězeno 26/08/2009 v 23:12
zdroj uživatelem

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more