SQL
in [OOP]
|
From: frebe on 29 Jan 2006 06:11 > Your original question was: "Can you name any other product offering > transaction support for things not within their domain?" My original claim was: "A RDBMS provide very useful transaction services." Others claimed that the transaction feature in a RDBMS was not so useful. Fredrik Bertilsson http://butler.sourceforge.net
From: frebe on 29 Jan 2006 06:20 > For my application I was forced to implement a sort of my own > higher-order GC over the DBMS, because triggers were unable to > collect what and how I needed it. I don't understand in what way this is related to my previous posting. > Yes, because containers are decoupled from resource management > for a good reason. Is this an argument for not using a RDBMS? If yes, what does you suggest to use instead? Direct file access? > There cannot be universal resource manager. Agree. A RDBMS provide one implementation. > Therefore all good container libraries are usually designed to be > independent on resource management. But the resource management can't be independent on the container library. > it is [sometimes] possible to implement that on top of > existing components. That is what the RDBMS do. > This is the power of OO (ADT) software design > paradigm: an ability to decompose larger problems into relatively > independent smaller ones. In what way does this discard the use of a RDBMS? Are you claiming that this "power" is unique to OO software design? Fredrik Bertilsson http://butler.sourceforge.net
From: Christian Brunschen on 29 Jan 2006 07:09 In article <1138512614.116951.150640(a)g49g2000cwa.googlegroups.com>, frebe <fredrik_bertilsson(a)passagen.se> wrote: >> Why should I be precluded from using a class library that offers me some >> reusable functionality? >Why should I be precluded from using a component (RDBMS) that offers me >some resusable functionality? You're not - you showed me precisely a solution that uses an RDBMS, including a query language; and I showed you a solution that uses objects, including some pre-written ones. >>>As I showed in my customer order example, direct references (pointers) >>>may not always be the best way to structure data. >> I disagree that you showed any such thing: your example didn't show that a >> relational representation was significantly better than one using objects >> referencing one another. >I showed a problem with a very simple SQL solutions. You was not able >to show a solution using objects referencing one another. Actually, the solution that I showed was exactly that: a solution with objects simply referencing one another. In your solution, you presumed that your data were appropriately modelled for a relational database; I simply presumed that the data in my case were modelled appropriately for an object-oriented aapproach. >Instead you >needed a SQL-like query language to provide a solution. No 'query language' involved, and certainly nothing 'SQL-like': Cocoa's 'key-value coding' is an extremely simple and straightforward mechanism, which simply allows the use of 'keys' to access attributes of an object (whether they offer direct access to data, or through methods that calculate the values for the keys); added to this mechanism is a simple 'key path' mechanism (allowing you to specify a multi-key path all in one go, rather than having to invoke each step separately), as well as the fact that arrays and sets allow simple operations to be performed (the '@unionOfSets' part). Apple's documentation on key-value coding is available at <http://developer.apple.com/documentation/Cocoa/Conceptual/KeyValueCoding/> .. I *could* have written all of these little steps separately; I simply chose to use some pre-existing functionality. But, if you insists - and without using any key-value-coding shortcuts, but presuming that the 'City' class has a method 'customers' that returns the set of customers living in that city, and that the 'Customer' class similarly has a method 'orders' returning a set of the orders for that customer (which is how I would model it): City *city = /* ... */; NSMutableSet *orders = [NSMutableSet set]; NSEnumerator *costumerEnumerator = [[city customers] objectEnumerator]; Customer *customer; while ((customer = [customerEnumerator next]) != nil) { [orders unionSet:[customer orders]]; } At this point, the 'orders' set will contain those orders that belong to customers in the specified city. This can of course be wrapped into a little method in the 'City' class: @implementation City (CustomerOrder) /* ... */ - (NSSet *)customerOrders { NSMutableSet *orders = [NSMutableSet set]; NSEnumerator *customerEnumerator = [[self customers] objectEnumerator]; Customer *customer; while ((customer = [customerEnumerator next]) != nil) { [orders unionSet:[customer orders]]; } return orders; } /* ... */ @end So now, the code - without using any 'trickery' - becomes [city customerOrders]; >> (the code you present doesn't appear to extract the orders for customers >> in a given city, but simply the orders of all customers?) >q = orderTable.createQuery(); >q.join(customerTable); >q.setFilter(customerTable.city().eq(city)); > >> I suggest you take a look at Apple's WebObjects, which includes EOF, a >> powerful and mature object-relational mapping tool. >The differences between ORM tools and butler is that a ORM tool need a >mapping file. Butler works directly on the RDB metadata. WebObjects can extract the metadata from the RDBMS to automatically create the mapping; this can even be done at run-time, at which point the mapping basically becomes cache for the database constraints. >> Using objects, the objects themselves can maintain referential integrity >But you have to code it by yourself, or? No, I'd use the appropriate methods for inserting and removing objects from relationships, which would do the necessry work to maintain referential integrity. >> I may want generic access to the objects, but not to their storage >> representation. >As pointed out many times before, SQL is not a storage representation. >It is a generic way to manage data. How the data is stored on disk is >completely hidden. From the point of view of code that uses a database, the database is a storage mechanism, and some representation of the data is thus stored in the database. Whether the database then uses the same representation that it exposes for however it stores the data on disk or in memory is not the point. But from the point of view of any code that uses the database, it's a representation of data. >Fredrik Bertilsson >http://butler.sourceforge.net Best wishes, // Christian Brunschen
From: Dmitry A. Kazakov on 29 Jan 2006 08:23 On 29 Jan 2006 03:20:43 -0800, frebe wrote: >> Yes, because containers are decoupled from resource management >> for a good reason. > Is this an argument for not using a RDBMS? That depends on concrete application. RDBMS aren't universal in general and especially in terms of resource management. They represent one possible solution. >> Therefore all good container libraries are usually designed to be >> independent on resource management. > But the resource management can't be independent on the container > library. It can. Consider GC and containers of references. >> it is [sometimes] possible to implement that on top of >> existing components. > That is what the RDBMS do. No, I would say that they represent rather a monolithic solution. This has advantages and disadvantages. >> This is the power of OO (ADT) software design >> paradigm: an ability to decompose larger problems into relatively >> independent smaller ones. > > In what way does this discard the use of a RDBMS? No. Relatively to OO it considers RDBMS as a tool, rather than a concurrent paradigm. IMO, there cannot be opposition OO vs. RDBMS. It is like to argue what is better OO or floating-point numbers. To continue the analogy: the place of SQL is one of the IEEE standard of floating-point numbers: a data presentation model. > Are you claiming that > this "power" is unique to OO software design? That depends on the class of problems we are considering. The context is essential. The class of problems efficiently decomposable in SQL is much narrower than one of OO and software design in general. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: frebe on 29 Jan 2006 10:04
>> But the resource management can't be independent on the container >> library. > It can. Consider GC and containers of references. Can you give any pointer to any existing (transaction) resource manager that can be used to any container library? I guess that you at least need an adapter. >> That is what the RDBMS do. > No, I would say that they represent rather a monolithic solution. I don't know if I would call a RDBMS like hsqldb with a footprint < 1MB monilothic. And if you really want to use a RDBMS without transactional support, try an early version of MySQL. On top you can use your own resource manager. Fredrik Bertilsson http://butler.sourceforge.net |