object databases
in [OOP]
|
From: frebe73 on 8 Nov 2006 06:27 > > I already showed to you that using embedded SQL gives you a less > > verbose source code. The impedance mismatch is avoided by not mapping > > classes to tables. > > No, the impedance mismatch is still there, as the mismatch is about > thinking in objects -> thinking in set oriented data. If you look at www.thethirdmanifesto.com you can find some material that explains why objects and sets are orthogonal issues. > You do the conversion with your own sql statements. If I have an > entity which is mapped onto 2 tables because it's a subtype of another > entity, I'm working with a single object and save a single object. You > have to write 2 queries, first the supertype one, then the subtype one. > When deleting the same entity, you too have to write 2 queries, but now > in reverse order. That's solving the mismatch in code yourself, as it > otherwise is left to the o/r mapper. This is easily solved by updatable views (which is supported by major database vendors). > > What is DAG and how does that corresponds to your customer/order > > example? > > Directed Acyclic Graph. > Customer <- Order <- OrderDetails > |----> Employee > > etc. > > '<-' == depends on. > > When working with objects in memory which are related to eachother, > you will be working with object graphs as that's more easier and fits > into the way OOD is done. For the last time, I don't work with object graphs. I work with relations. Problems related to objects graphs are not relevant for me. > Your problem is that you by yourself have to figure out what the order > is of ALL the entities in the graph to save all the changes (and what > are the changes btw? You've to figure out which fields have changed and > if the object is new or not new etc.) I don't buffer changes in memory objects. I call update immediatly when I want to change some data. I don't have your order problem. > this problem shows its ugly head when you for example have a system > where a GUI part doesn't contain knowledge how to save the data managed > by the GUI part, i.e. an order entry form. The problem only exists if you forbid the GUI to use SQL. > The form then will push down a changed object graph or collection of > objects and doesn't knwo what the order is or which objects are changed > as that's not important, as we're using OO, not flat-file C code. Another argument for not using object graphs.... > You then have to figure out which entities are new, which aren't, > which have to be saved first, which after that, which syncs with which > etc. I don't have to do that. I call 1 method and it's done. That's > what makes the system more efficient and less error prone as it doesn't > matter if an FK is changed, my code will still work. Because I don't buffer changes in objects, I don't have any sync problem. > > > Now something changes. > > > > What changes? The database schema, the application code, or? > > any change that will make the order in which elements have to be saved > different. > > and make no mistake: the order in which entities can be saved MIGHT be > different based on data, i.e. in entities with a relation to self. Can you be more specific please? > > > Where to change your list of sql statements so > > > the code works OK? I don't have to think about that. > > > > Can you give an example using your customer/order scenario? > > Same code as I gave before. the sorting of the complete graph is done > by the o/r mapper layer, which also checks which entities to save and > which to ignore, which fields to update and if an entity has to be > updated or inserted etc. Sorting is done by the database. The GUI is responsible for determinating which data that should be updated or inserted. > The relational model is very important, I won't deny that, but I think > you overlook something: what you and I call semantically 'Customer' or > 'Order' is effectively the same abstract entity. If you look at THAT, > and not at where it's physically represented, you'll undersatnd it > doesn't matter where you start from: the rest is plumbing code. I don't care about how 'Customer' is phisically represented. The database hides that from me. > > > Sure, if you want to spend time on that and doing all the sql > > > yourself, why not? > > > > I already showed you I have to write fewer lines of code than you. > > I don't think so. > // get all customers from germany and their orders. This will give > // two queries, not 1 + #of customers fetched. Everything is merged > // for me into a graph. > > // private member variable of form: > private EntityCollection<CustomerEntity> _customers; > > > // init code > _customers = new EntityCollection<CustomerEntity>(); > PrefetchPath2 path = new PrefetchPath2((int)EntityType.CustomerEntity); > path.Add(CustomerEntity.PrefetchPathOrders); > RelationPredicateBucket filter = new RelationPredicateBucket( > (CustomerFields.Country== "Germany")); > using(DataAccessAdapter adapter = new DataAccessAdapter()) > { > // fetch graph > adapter.FetchEntityCollection(_customers, filter, path); > } > > // bind to master-detail grid > myCustomerDataGrid.DataSource = _customers; > myOrderDataGrid.DataSource = _customers; > myOrderDataGrid.DataMember = "Orders"; > > //... > //... in the save button click event handler: > using(DataAccessAdapter adapter = new DataAccessAdapter()) > { > adapter.SaveEntityCollection(_customers); > } You don't show the source code for your data grid, so I suppose I am allowed to use my own generic master/child grid. All you have to supply to the grid is the SQL statements for retrieving and writing the data. In PHP it would look something like this: myGrid.masterSelect = <<<SQL select customerid, companyname, contactperson from customer where country='Germany' SQL; myGrid.childSelect = <<<SQL select orderid, orderdate, amount from order where customerid=$customerid SQL; myGrid.masterUpdate = <<<SQL update customer set companyname=$companyname, contactperson=$contactperson where customerid=$customerid SQL; myGrid.display() or myGrid.save() I assume that layout info and additional business logic need to be added to the grid as extra properties and function pointers, but you don't supply them either. > Then I save the whole graph with effectively 1 line of code. Me too.
From: Frans Bouma on 9 Nov 2006 02:30 Sasa wrote: > > "Frans Bouma" <perseus.usenet.NOSPAM.(a)xs4all.nl> wrote in message > news:xn0eth1al6dlbp002(a)news.xs4all.nl... > > frebe73(a)gmail.com wrote: > > Also, the code is db agnostic: it works on any db supported by the > > O/R mapper. > > Since you brought this up - are there mappers which support non > relational storages (XML, proprietary formats, etc.)? in theory that's indeed possible, in practise I'm not sure I know any o/r mapper out there which supports non-relational storages, like XML or what have you. FB -- ------------------------------------------------------------------------ Lead developer of LLBLGen Pro, the productive O/R mapper for .NET LLBLGen Pro website: http://www.llblgen.com My .NET blog: http://weblogs.asp.net/fbouma Microsoft MVP (C#) ------------------------------------------------------------------------
From: AndyW on 9 Nov 2006 02:53 On 08 Nov 2006 09:46:28 GMT, "Frans Bouma" <perseus.usenet.NOSPAM.(a)xs4all.nl> wrote: >frebe73(a)gmail.com wrote: > >> > sql syntax checking is something else than checking names etc. I >> > couldn't find info about that but if you say so, let it be so. The >> > thing that's still there is that you are writing hardcoded sql >> > strings and doing the impedance mismatch solving YOURSELF instead >> > of a piece of code which is in general more suitable for these kind >> > of things. >> >> I already showed to you that using embedded SQL gives you a less >> verbose source code. The impedance mismatch is avoided by not mapping >> classes to tables. > > No, the impedance mismatch is still there, as the mismatch is about >thinking in objects -> thinking in set oriented data. I would agree with that and I think its one of the issues between people that work with relational data vs people that work with object data. Its like a math expert claiming that they really dont thing logically.
From: topmind on 9 Nov 2006 13:05 AndyW wrote: > On 08 Nov 2006 09:46:28 GMT, "Frans Bouma" > <perseus.usenet.NOSPAM.(a)xs4all.nl> wrote: > > >frebe73(a)gmail.com wrote: > > > >> > sql syntax checking is something else than checking names etc. I > >> > couldn't find info about that but if you say so, let it be so. The > >> > thing that's still there is that you are writing hardcoded sql > >> > strings and doing the impedance mismatch solving YOURSELF instead > >> > of a piece of code which is in general more suitable for these kind > >> > of things. > >> > >> I already showed to you that using embedded SQL gives you a less > >> verbose source code. The impedance mismatch is avoided by not mapping > >> classes to tables. > > > > No, the impedance mismatch is still there, as the mismatch is about > >thinking in objects -> thinking in set oriented data. > > I would agree with that and I think its one of the issues between > people that work with relational data vs people that work with object > data. It seems one big difference between OO fans and relational fans is that OO fans think that these should be seperate people or specialties, while relational fans think they should be the same people because relational is or can be a key app tool and not just a "storage" tool. That battle continues, for good or bad... > > Its like a math expert claiming that they really dont thing logically. -T-
From: Frans Bouma on 10 Nov 2006 04:00
topmind wrote: > > AndyW wrote: > > On 08 Nov 2006 09:46:28 GMT, "Frans Bouma" > > <perseus.usenet.NOSPAM.(a)xs4all.nl> wrote: > > > > > frebe73(a)gmail.com wrote: > > > > > >> > sql syntax checking is something else than checking names > > etc. I >> > couldn't find info about that but if you say so, let it > > be so. The >> > thing that's still there is that you are writing > > hardcoded sql >> > strings and doing the impedance mismatch solving > > YOURSELF instead >> > of a piece of code which is in general more > > suitable for these kind >> > of things. > > > > > > >> I already showed to you that using embedded SQL gives you a less > > >> verbose source code. The impedance mismatch is avoided by not > > mapping >> classes to tables. > > > > > > No, the impedance mismatch is still there, as the mismatch is > > > about > > >thinking in objects -> thinking in set oriented data. > > > > I would agree with that and I think its one of the issues between > > people that work with relational data vs people that work with > > object data. > > It seems one big difference between OO fans and relational fans is > that OO fans think that these should be seperate people or > specialties, while relational fans think they should be the same > people because relational is or can be a key app tool and not just a > "storage" tool. > > That battle continues, for good or bad... I don't see why there should be a battle. There's no black-white here, simply because solely using OO objects is problematic in some situations and so is pure set-based data. That's also why most mature O/R mappers offer a way to pull dynamic sets out of the DB based on meta-data available in the mappings, i.e. a list of some order attributes + the customer.companyname in a new set, including features to project this set onto different datastructures / classes if you want to. As long as people think that solely using entity representing objects covers 100% of the cases and also the other 'side' thinks everything set-based/oriented is fully usable as an OO construct in an OO program, these discussions won't end, but at the same time, they're as meaningless as the stupid debates whether stored procedures are better than dynamic SQL. FB -- ------------------------------------------------------------------------ Lead developer of LLBLGen Pro, the productive O/R mapper for .NET LLBLGen Pro website: http://www.llblgen.com My .NET blog: http://weblogs.asp.net/fbouma Microsoft MVP (C#) ------------------------------------------------------------------------ |