SQL
in [OOP]
|
From: frebe on 29 Jan 2006 10:29 > 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. Your original solution looked like this: [city valueForKeyPath:@"custome...(a)unionofSets.orders"]; I suppose that "custome...(a)unionofSets.orders" can be considered as a query or part of a query. If you claim that this solution is just using objects, when are the statement below is also just using objects. conn.createStatement("select * from customers where city=?"); > City *city = /* ... */; > NSMutableSet *orders = [NSMutableSet set]; > NSEnumerator *costumerEnumerator = [[city customers] objectEnumerator]; > Customer *customer; > while ((customer = [customerEnumerator next]) != nil) { > [orders unionSet:[customer orders]]; > } How do you navigate to the city object, by a map or? Lets say we add an extra criteria, the order status has to be "pending". select * from order join customer on customer.id=order.customerid where customer.city=? and order.status="pending" Will you still start with the city object? Or will you start with the OrderStatus object? Lets say that the number of cities are low and the percentage of orders that are "pending" are low, that would be an very ineffective way of finding the corrects orders. On the other hand, if the number of cities are high and the percentage of "pending" orders are high, starting from the city object would be a good idea. This kind of decision can be made by the RDBMS optimizer totally hidden from the application. In your network scenario, the navigational path is hardwired in the application and impossible to automatically optimize. Also, would you really have pointers the City and OrderStatus objects to every order/customer. For every searchable attribute, you need to maintain an extra map. Lets say you didn't realized that you would need to find customers using a given city, when you first created the application. To be able to do this search, you have to add an extra set of customer references in the city class and update all existing city instances using a linear traversal of all customer instances. Not very flexible to future changes? Fredrik Bertilsson http://butler.sourceforge.net
From: Dmitry A. Kazakov on 29 Jan 2006 10:31 On 29 Jan 2006 07:04:36 -0800, frebe wrote: >>> 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 didn't say any. I just said that it is technically possible. It is also natural for people to consider them separated. [ That often leads to nasty surprises, but safe software construction is another story. ] >>> 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. Monolithic does not mean size, but the point you are arguing for - that containers and resource management cannot be separated. [ Size is a bad metric. There exist languages where just one line of source code might be too much to understand. Examples: C++ templates, pattern expressions, APL. ] -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: frebe on 29 Jan 2006 11:51 > Monolithic does not mean size, but the point you are arguing for - that > containers and resource management cannot be separated. Container and resource management may be separated, but the resource management has to know about the resource that is supposed to be managed. The resource does not need to know anything about the manager. Fredrik Bertilsson http://butler.sourceforge.net
From: Dmitry A. Kazakov on 29 Jan 2006 14:41 On 29 Jan 2006 08:51:26 -0800, frebe wrote: >> Monolithic does not mean size, but the point you are arguing for - that >> containers and resource management cannot be separated. > > Container and resource management may be separated, but the resource > management has to know about the resource that is supposed to be > managed. The resource does not need to know anything about the manager. That again is a centralized model, which being undoubtedly useful, nevertheless should be taken with a grain of salt. There could be situations when distributed, cooperative management of resources knowing and changing their managers could be an advantage. [ Are you always satisfied with your boss? (:-)) ] -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: topmind on 29 Jan 2006 15:20
Dmitry A. Kazakov wrote: > On 28 Jan 2006 22:43:11 -0800, topmind wrote: > > >> OK, show us some use cases that support your assertions, then - that show > >> that it is even _possible_. Show how a 'general-purpose string > >> matching/finding tool' is a 'general-purpose tool' _outside_ of its domain > >> - which is finding predefined patters within strings. > > > > That is an interesting challenge that I am not up to. I've encountered > > programmers who claimed they could do such and they gave some > > interesting examples of what can be done. However, I don't have the > > link right now. I suggest you try a Perl forum perhaps. Generally they > > can use strings to represent stacks, queues, lists, passible > > "functions" (code snippets that are later Eval'ed), etc. and regex's to > > parse and unparse such strings. > > Write a pattern that inverses an arbitrary string: "abcd" --> "dcba". You > cannot do it with regular expressions, which are very limited in power. > SNOBOL can this, but it is Turing-complete language. [ For all you need a > user stack or equivalent and recursion. Standard regular expressions lack > both. ] Again, the challenge was to show that *most*, or at least a large percent could be processed via the regex engine. That does not mean that everything has to. There are indeed things that regex's can't do and things that DB's and query languages can't do. I am not disputing that. It is a matter of percentage and practicality, not a claim of Turing Complete or handling the *entire* processing load. The Yin does not have to be able to do everything the Yang does in order for Yin and Yang to work well together. Showing that Yin can do everything Yang does and visa versa does not necessarily mean they do it well by themselves nor that a complimentary pairing is not a net improvement. (Note that the regex thing was only an illustrative example of partitioning, not a recommendation for regex's.) > > -- > Regards, > Dmitry A. Kazakov > http://www.dmitry-kazakov.de -T- |