OO vs. RDB challenge
Allegations have veen made recently (Application vs. Business Logic thread) that only if we had enough peristent RAM so that we can get rid of Oracle and its ilk, milk and honey will flow all across the OO land now freed from Object Relational (Psychological) Impedance Mismatch. Claims have been handwaved across this newsgroups that core functionality implemented by DBMS engines was not needed because it would be trivially covered by the brave OO coders writing their ADTs on a case by case basis. Since this is old news, I thought I refer those brave OO coders to something I created specifically for such occasions: http://c2.com/cgi/wiki?ManyToManyChallenge I'm waiting to see how OO weenies out there put their code where their mouth is. In particular I would stress the requirement that whatever class or object (for object based, Java Script kind of guys) you create to manage the many to many relationship , it should be usable from the calling context without any fear of deadlock or spurious results in a multi-threaded environment. Again, persistence is not an issue -- data need not be persisted (imagine you had your nvram or whatever). --Costin
c_cozianu
comp.object
3218 articles. 
1 followers.
220 Replies
1736 Views
AndyW wrote: > We dont bother using all that mindless obfusticated rubbish you > relational folks do :) Yeah, we OO guys have our own mindless obfusticated rubbish so we don't need yours! :) Jeff Brooks
jeff_brooksIsn't an "intersection" the classic method for representing many-to-many relationships in RDBs? Given two tables with M-to-M between them, a 3rd table exists to hold the PKs for both tables to show the intersection. I've done the same thing in Smalltalk. An instrument can have many owners and an owner can have many instruments. An instrument object has a collection of owners and an owner has a collection of its instruments. In fact, there's only two objects using OO, the instrument and the owner, but in RDBs there must be three. It could be argued the intersection table exists in OO but is split in-half between the instruments and owners. The same could be done with users and groups. An RDB must have three tables, user, group and userGroup. In Smalltalk my user objects can have a collection of groups, and each group can have a collection of users. What am I missing?
tgagneOn Wed, 09 Mar 2005 13:06:10 -0800, Costin Cozianu <c_cozianu@hotmail.com> wrote: >Allegations have veen made recently (Application vs. Business Logic >thread) that only if we had enough peristent RAM so that we can get rid >of Oracle and its ilk, milk and honey will flow all across the OO land >now freed from Object Relational (Psychological) Impedance Mismatch. > >Claims have been handwaved across this newsgroups that core >functionality implemented by DBMS engines was not needed because it >would be trivially covered by the brave OO coders writing their ADTs on >a case by case basis. > >Since this is old news, I thought I refer those brave OO coders to >something I created specifically for such occasions: > >http://c2.com/cgi/wiki?ManyToManyChallenge > >I'm waiting to see how OO weenies out there put their code where their >mouth is. > >In particular I would stress the requirement that whatever class or >object (for object based, Java Script kind of guys) you create to manage >the many to many relationship , it should be usable from the calling >context without any fear of deadlock or spurious results in a >multi-threaded environment. Again, persistence is not an issue -- data >need not be persisted (imagine you had your nvram or whatever). > > >--Costin Sorry, but your argument is pointless. Relationships are managed by the DB on OO (at least thats how I do it), so why would I want to "manage" them or even bother with writing code that wastes time and effort. I suspect you have no idea about OO databases and how to create object schemas. In C++ we use pointers from one object to another, in Objectstore you just use that pointer and the DB does the work of making the data transient. We dont bother using all that mindless obfusticated rubbish you relational folks do :)
foo_On Thu, 10 Mar 2005 03:50:05 GMT, Jeff Brooks <jeff_brooks@nospam.com> wrote: >AndyW wrote: > >> We dont bother using all that mindless obfusticated rubbish you >> relational folks do :) > >Yeah, we OO guys have our own mindless obfusticated rubbish so we don't >need yours! :) > >Jeff Brooks Yes - our obfustication is much more superior than the RDB folks - We use Object Obfustication :)
On Thu, 10 Mar 2005 16:49:26 +1200, AndyW <foo_@bar_no_email.com> wrote: >Relationships are managed by >the DB on OO This is gibberish. >I suspect you have no idea about OO databases and how to create object >schemas. What is an OO database to you? >In C++ we use pointers from one object to another, in Objectstore you >just use that pointer and the DB does the work of making the data >transient. That is the obsolete network approach. Regards
alfredo_novoaOn Wed, 09 Mar 2005 13:06:10 -0800, Costin Cozianu <c_cozianu@hotmail.com> wrote: >http://c2.com/cgi/wiki?ManyToManyChallenge > >I'm waiting to see how OO weenies out there put their code where their >mouth is. I think that many of them would be satisfied with this "solution": theMotherOfAllObjects.SolveChallenge(CostinsChallenges.ManyToMany); At least that's the way they "solved" my trivial challenges :) Regards
Thomas Gagne wrote: > In fact, there's only two objects using OO, the instrument and the > owner, but in RDBs there must be three. It could be argued the > intersection table exists in OO but is split in-half between the > instruments and owners. > What am I missing? It is common to have 3 classes in OO as well. Taking your owner/instrument example it is common to have extra data associated with each relation, say for example last service date. -- Marc Rohloff
marcrohloff_ngAndyW wrote: > On Wed, 09 Mar 2005 13:06:10 -0800, Costin Cozianu > <c_cozianu@hotmail.com> wrote: > > >>Allegations have veen made recently (Application vs. Business Logic >>thread) that only if we had enough peristent RAM so that we can get rid >>of Oracle and its ilk, milk and honey will flow all across the OO land >>now freed from Object Relational (Psychological) Impedance Mismatch. >> >>Claims have been handwaved across this newsgroups that core >>functionality implemented by DBMS engines was not needed because it >>would be trivially covered by the brave OO coders writing their ADTs on >>a case by case basis. >> >>Since this is old news, I thought I refer those brave OO coders to >>something I created specifically for such occasions: >> >>http://c2.com/cgi/wiki?ManyToManyChallenge >> >>I'm waiting to see how OO weenies out there put their code where their >>mouth is. >> >>In particular I would stress the requirement that whatever class or >>object (for object based, Java Script kind of guys) you create to manage >>the many to many relationship , it should be usable from the calling >>context without any fear of deadlock or spurious results in a >>multi-threaded environment. Again, persistence is not an issue -- data >>need not be persisted (imagine you had your nvram or whatever). >> >> >>--Costin > > > Sorry, but your argument is pointless. Relationships are managed by > the DB on OO (at least thats how I do it), so why would I want to > "manage" them or even bother with writing code that wastes time and > effort. > > I suspect you have no idea about OO databases and how to create object > schemas. > > In C++ we use pointers from one object to another, in Objectstore you > just use that pointer and the DB does the work of making the data > transient. > > We dont bother using all that mindless obfusticated rubbish you > relational folks do :) > > Handwaving does not count. Code does
Thomas Gagne wrote: > Isn't an "intersection" the classic method for representing many-to-many > relationships in RDBs? Given two tables with M-to-M between them, a 3rd > table exists to hold the PKs for both tables to show the intersection. > > I've done the same thing in Smalltalk. An instrument can have many > owners and an owner can have many instruments. An instrument object has > a collection of owners and an owner has a collection of its instruments. > > In fact, there's only two objects using OO, the instrument and the > owner, but in RDBs there must be three. It could be argued the > intersection table exists in OO but is split in-half between the > instruments and owners. > > The same could be done with users and groups. An RDB must have three > tables, user, group and userGroup. In Smalltalk my user objects can > have a collection of groups, and each group can have a collection of users. > > What am I missing? CREATE TABLE Users ( user_id INTEGER NOT NULL PRIMARY KEY, username VARCHAR NOT NULL, CONSTRAINT groups_uq UNIQUE (username)); CREATE TABLE Groups (group_id INTEGER NOT NULL PRIMARY KEY, group_name VARCHAR , CONSTRAINT groups_uq UNIQUE (group_name)); CREATE TABLE r_users_groups ( user_id INTEGER NOT NULL , group_id INTEGER NOT NULL, CONSTRAINT r_users_groups_pk PRIMARY KEY (user_id, group_id), CONSTRAINT r_users_groups_fk1 FOREIGN KEY (user_id) REFERENCES users ON DELETE CASCADE ON UPDATE CASCADE, CONSTRAINT r_users_groups_fk2 FOREIGN KEY (group_id) REFERENCES groups ON DELETE CASCADE ON UPDATE CASCADE ) CREATE INDEX r_user_groups_idx1 ON r_user_groups (group_id); That's the response to the challenge in SQL. Given the above tables setup, the client is exactly '''one''' statement away from: 1) creating a user 2) creating a group 3) associating a user with a group 4) removing the association between a user and a group 5) deleting a user 6) deleting a group 7) selecting users or groups based on simple criteria Not only the above operations are available, they're also safe under concurrent access, and can be wrapped in transactions together with other operations so that if any of them fail the whole transaction will rollback so that data is left in a consistent state. I have yet to see a OO programming language based solution in comparable lines of code (which shows that the tools of the trade in SQL are pretty high level stuff compared with the pointers and the arrays RCM was talking about), and to make it thread safe would be even a hell of a lot more work. And this has nothing to do with Persistence. It's strictly about data access functionality. Which proves that the whole handwaving about RAM technology displacing DBMSes is much ado about nothing.
AndyW wrote: > > I suspect you have no idea about OO databases and how to create object > schemas. > I think I do, but I still find it a little hard to believe. If understand this correctly, back from the days many years ago when I studied Object Store very closely, they are little more than a persistent store for your C++ or smalltalk or Java thingies, they appear to offer no abstraction of the concept of an object, so you can't, for example, seamingless load Java or C# objects from an OO database in which C++ objects were stored. Have I got that right? Regards, Daniel Parker
danielaparker2On Thu, 10 Mar 2005 07:53:36 -0800, Costin Cozianu
<c_cozianu@hotmail.com> wrote:
Here is my non SQL solution :)
var Users relation { User Char };
var Groups relation { Group Char };
var UsersGroups relation { User Char, Group Char }
foreign key User references Users on { update, delete } cascade
foreign key Group references Groups on { update, delete } cascade;
>That's the response to the challenge in SQL. Given the above tables
>setup, the client is exactly '''one''' statement away from:
>1) creating a user
insert into Users relation { tuple { User 'Alfredo' } };
>2) creating a group
insert into Groups relation { tuple { Group 'DBMS Folks' } };
>3) associating a user with a group
insert into Groups relation { tuple { User 'Alfredo' , Group 'DBMS
Folks' } };
>4) removing the association between a user and a group
delete Groups where User = 'Alfredo' and Group = 'DBMS Folks';
>5) deleting a user
delete Users where User = 'Alfredo';
>6) deleting a group
delete Groups where Group = 'DBMS Folks';
>7) selecting users or groups based on simple criteria
Select all the users of the 'DBMS Folks' group:
(UsersGroups where Group = 'DBMS Folks') { Users };
Select my groups :)
(UsersGroups where User = 'Alfredo') { Groups };
Regards
On Thu, 10 Mar 2005 17:37:06 +0100, Alfredo Novoa <alfredo_novoa@hotmail.com> wrote: >>4) removing the association between a user and a group > >delete Groups where User = 'Alfredo' and Group = 'DBMS Folks'; This should be: delete UsersGroups where User = 'Alfredo' and Group = 'DBMS Folks'; Regards
Responding to Cozianu... > Allegations have veen made recently (Application vs. Business Logic > thread) that only if we had enough peristent RAM so that we can get rid > of Oracle and its ilk, milk and honey will flow all across the OO land > now freed from Object Relational (Psychological) Impedance Mismatch. I don't think so. If all that data had to be shared across many applications solving different problems, one would still have the fundamental problem of providing generic data access and representation in RAM, which is what the RDBMS paradigm provides. So the Oracle equivalent would still exist as in interface to those client applications. > > Claims have been handwaved across this newsgroups that core > functionality implemented by DBMS engines was not needed because it > would be trivially covered by the brave OO coders writing their ADTs on > a case by case basis. > > Since this is old news, I thought I refer those brave OO coders to > something I created specifically for such occasions: > > http://c2.com/cgi/wiki?ManyToManyChallenge I think it's a straw man challenge. The challenge is to emulate data storage techniques and technologies when implementing from scratch using OO construction. Of course the OO version will be much wordier than the SQL version. That's because the SQL infrastructure has a gazillion low-level lines behind it that the OO code would have to provide explicitly. More to the point, emulating RDB data storage infrastructure would be an inherently unsuitable application of OO techniques. That's because data storage is based upon the notion of context-free data representation and access. An RDB is optimized to provide general, shared access to data that is independent of how or why that data is used. OTOH, OO development is geared to solving individual problems in a very particular context. In addition, OO is geared to solving large, complex business problems. Thus the OO paradigm is based upon the tailoring (optimizing) data representation to a particular problem context. IOW, it is all about how to /use/ data. Therefore OO is an inappropriate paradigm to apply to basic data storage. Similarly, the table-based index searching for the RDB paradigm is inappropriate paradigm for solving individual business problems (other than traditional USER/CRUD processing). IOW, render unto the RDB the things that are generic data storage, render unto RAD the things that are CRUD/USER, and render unto OO development the things that are unique, complex problem solutions. ************* There is nothing wrong with me that could not be cured by a capful of Drano. H. S. Lahman hsl@pathfindermda.com Pathfinder Solutions -- Put MDA to Work http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman (888)OOA-PATH
h.lahmanH. S. Lahman wrote: ivalent would still exist as in interface to those client applications. > >> >> Claims have been handwaved across this newsgroups that core >> functionality implemented by DBMS engines was not needed because it >> would be trivially covered by the brave OO coders writing their ADTs >> on a case by case basis. >> >> Since this is old news, I thought I refer those brave OO coders to >> something I created specifically for such occasions: >> >> http://c2.com/cgi/wiki?ManyToManyChallenge > > > I think it's a straw man challenge. If it was a straw man somebody would know it down by code. Probably you meant Red Herring > The challenge is to emulate data > storage techniques and technologies when implementing from scratch using > OO construction. Where do you see "storage". I explicitly mentioned that persistence of that data is of no concern at all in the challenge. > Of course the OO version will be much wordier than the > SQL version. That's because the SQL infrastructure has a gazillion > low-level lines behind it that the OO code would have to provide > explicitly. > Or, if OO was so good at addressing the issues we'd have ready made OO abstraction in the form of either Ope Source (or commercial) libraries or even OO language featureas that would take care of the problems raised by my challenge. It's a many to many relationship. It's something discussed in almost all books on OO, except most don't show any code and none that I know of provide a sound solution (including the thread safety requirement). The problem is simple: you have a User * Group many to many relationship that the developer needs to manage. This is a particular instance. Another instance would be classA and classB. According to the OO theory one would even be able to create a reusable abstraction in one swift move to take care of both cases. Why not ? Isn't one of OO strong selling points about the creation of reusable abstractions ? > More to the point, emulating RDB data storage infrastructure would be an > inherently unsuitable application of OO techniques. That's because data > storage is based upon the notion of context-free data representation and > access. An RDB is optimized to provide general, shared access to data > that is independent of how or why that data is used. > Translation needed, for the "context-free" mumbo jumbo. Again we're mot talking about storage, we're talking strictly about safe data manipulation. > OTOH, OO development is geared to solving individual problems in a very > particular context. Yeah. You have a particular problem (or actually a part thereof). You have users and you have groups and your OO application needs to be able to do the operations that I enumerated. > In addition, OO is geared to solving large, complex > business problems. ??? > Thus the OO paradigm is based upon the tailoring > (optimizing) data representation to a particular problem context. IOW, > it is all about how to /use/ data. > Yeah, you have particular problem and particular context. Think of it as a student exercise. You have to implement part of the OO application that manages users and groups and the relation between them, while doing so safely and in a multi-threaded environment. > Therefore OO is an inappropriate paradigm to apply to basic data > storage. Similarly, the table-based index searching for the RDB > paradigm is inappropriate paradigm for solving individual business > problems (other than traditional USER/CRUD processing). > Who stops you fromm using an out of the box Hastable, or TreeMap or any other libraries ubiquous in Java/C#/C++/Python ? You don't have to use an index, it is not mandated as part of the specification. > IOW, render unto the RDB the things that are generic data storage, > render unto RAD the things that are CRUD/USER, and render unto OO > development the things that are unique, complex problem solutions. > Again, storage is not a consideration. Safe data manipulation is. The conclusion is that OO techniques alone (includingn ADTs, pointers arrays, etc) are not good enough to tackle *extremely* simple data manipulation problems. Thus most OO business systems rely on a SQL DBMS to delegate some of the data manipulation functionality that can't be adequately handled in OO languages.
Marc Rohloff wrote: > Thomas Gagne wrote: > >>In fact, there's only two objects using OO, the instrument and the >>owner, but in RDBs there must be three. It could be argued the >>intersection table exists in OO but is split in-half between the >>instruments and owners. > > >>What am I missing? > > > It is common to have 3 classes in OO as well. Taking your > owner/instrument example it is common to have extra data associated > with each relation, say for example last service date. > When there is, you're right. There is a third class "intersection" class. It's amazing how similar they are, OO and RDB.
On Thu, 10 Mar 2005 11:27:52 -0800, Costin Cozianu <c_cozianu@hotmail.com> wrote: >> In addition, OO is geared to solving large, complex >> business problems. > >??? He meant that OO can not adequately handle this problem because it is too simple :) These swindlers lack any shame. >The conclusion is that OO techniques alone (includingn ADTs, pointers >arrays, etc) are not good enough to tackle *extremely* simple data >manipulation problems. Thus most OO business systems rely on a SQL DBMS >to delegate some of the data manipulation functionality that can't be >adequately handled in OO languages. The problem is that most OO business systems only delegate SOME of the data manipulation that can't be adequately handled in OO languages. Regards
Costin Cozianu wrote: > > Again, storage is not a consideration. Safe data manipulation is. > > The conclusion is that OO techniques alone (includingn ADTs, pointers > arrays, etc) are not good enough to tackle *extremely* simple data > manipulation problems. Thus most OO business systems rely on a SQL DBMS > to delegate some of the data manipulation functionality that can't be > adequately handled in OO languages. You seem to be completely ignoring all the systems, many of them complex, that run on Gemstone/S. I think the following few lines of Smalltalk code seem to handle your User - Group case. Throw in Gemstone and you've got everything you need. I don't have access to Gemstone right now, so the following only uses standard Smalltalk. You can file it into Squeak and try it out. Model subclass: #Group instanceVariableNames: 'name users' classVariableNames: 'AllGroups' poolDictionaries: '' category: 'Work-Groups'! !Group methodsFor: 'initialize-release' stamp: 'jau 3/10/2005 14:15'! initialize users := Set new! ! !Group methodsFor: 'querying' stamp: 'jau 3/10/2005 15:33'! containsUser: aUser ^users contains: aUser! ! !Group methodsFor: 'accessing' stamp: 'jau 3/10/2005 15:06'! name ^name! ! !Group methodsFor: 'accessing' stamp: 'jau 3/10/2005 15:06'! name: aString name := aString! ! !Group methodsFor: 'accessing' stamp: 'jau 3/10/2005 15:06'! users ^users! ! "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "! Group class instanceVariableNames: ''! !Group class methodsFor: 'accessing' stamp: 'jau 3/10/2005 15:37'! addGroup: aGroup self allGroups add: aGroup! ! !Group class methodsFor: 'accessing' stamp: 'jau 3/10/2005 15:09'! allGroups AllGroups isNil ifTrue: [ AllGroups := Set new ]. ^AllGroups! ! !Group class methodsFor: 'accessing' stamp: 'jau 3/10/2005 15:38'! removeGroup: aGroup self allGroups remove: aGroup! ! !Group class methodsFor: 'examples' stamp: 'jau 3/10/2005 15:38'! test "Group test" | john adminGroup | "1) creating a user" john := User new name: 'John'. User addUser: john. "2) creating a group" adminGroup := Group new name: 'Administrator'. Group removeGroup: adminGroup. "3) associating a user with a group" adminGroup users add: john. "4) removing the association between a user and a group" adminGroup users remove: john. "5) deleting a user" User removeUser: john. "6) deleting a group" Group removeGroup: adminGroup. "7) selecting users or groups based on simple criteria" User allUsers select: [ :each | each name == 'John' ]. Group allGroups select: [ :each | each name == 'Administrator' ].! ! Model subclass: #User instanceVariableNames: 'name' classVariableNames: 'AllUsers' poolDictionaries: '' category: 'Work-Groups'! !User methodsFor: 'accessing' stamp: 'jau 3/10/2005 15:07'! name ^name! ! !User methodsFor: 'accessing' stamp: 'jau 3/10/2005 15:07'! name: aString name := aString! ! "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "! User class instanceVariableNames: ''! !User class methodsFor: 'accessing' stamp: 'jau 3/10/2005 15:29'! addUser: aUser self allUsers add: aUser! ! !User class methodsFor: 'accessing' stamp: 'jau 3/10/2005 15:08'! allUsers AllUsers isNil ifTrue: [ AllUsers := Set new ]. ^AllUsers! ! !User class methodsFor: 'accessing' stamp: 'jau 3/10/2005 15:36'! removeUser: aUser Group allGroups do: [ :each | (each containsUser: aUser) ifTrue: [ self error: 'User is referenced by a group.' ] ]. self allUsers remove: aUser.! ! Regards, John
jurberg1John Urberg wrote: > Costin Cozianu wrote: > >>Again, storage is not a consideration. Safe data manipulation is. >> >>The conclusion is that OO techniques alone (includingn ADTs, pointers > > >>arrays, etc) are not good enough to tackle *extremely* simple data >>manipulation problems. Thus most OO business systems rely on a SQL > > DBMS > >>to delegate some of the data manipulation functionality that can't be > > >>adequately handled in OO languages. > > > You seem to be completely ignoring all the systems, many of them > complex, that run on Gemstone/S. > As far as I remember from trying to read their documentation some time ago neither Gemstone/S nor Gemstone/Java had any particular class for managing relationships, and many smalltalkers with which I discussed related issues were always discussing about "roll your own sets and hashtables" approach. > I think the following few lines of Smalltalk code seem to handle your > User - Group case. Throw in Gemstone and you've got everything you > need. I don't have access to Gemstone right now, so the following only > uses standard Smalltalk. You can file it into Squeak and try it out. > Actually I try to read, Smalltalk printouts are not exactly nice (much better would be Python or Ruby) but as far as I can tell, you chose to hang user pointers from group objects which makes answering the query "what groups do this user belongs to ?" inefficient. Maybe I haven't mentioned in this newsgroup, but it is mentioned in the wiki page under the clause: " Navigating the relationship both ways in better than linear time " So you'd have to add the corresponding indexing structure (Set, Hashmap or whatever) either to the User object or in a global structure. More code to do the bookkeeping where in a SQL database is simply a matter of creating an index. After all these are added I think you are already at least triple the lines of code in the SQL setup. However, the essential part is this: your code is good for single threaded environments only. > Model subclass: #Group > instanceVariableNames: 'name users' > classVariableNames: 'AllGroups' > poolDictionaries: '' > category: 'Work-Groups'! > > !Group methodsFor: 'initialize-release' stamp: 'jau 3/10/2005 14:15'! > initialize > users := Set new! ! > > > !Group methodsFor: 'querying' stamp: 'jau 3/10/2005 15:33'! > containsUser: aUser > ^users contains: aUser! ! > > > !Group methodsFor: 'accessing' stamp: 'jau 3/10/2005 15:06'! > name > ^name! ! > > !Group methodsFor: 'accessing' stamp: 'jau 3/10/2005 15:06'! > name: aString > name := aString! ! > > !Group methodsFor: 'accessing' stamp: 'jau 3/10/2005 15:06'! > users > ^users! ! > > "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "! > > Group class > instanceVariableNames: ''! > > !Group class methodsFor: 'accessing' stamp: 'jau 3/10/2005 15:37'! > addGroup: aGroup > self allGroups add: aGroup! ! > > !Group class methodsFor: 'accessing' stamp: 'jau 3/10/2005 15:09'! > allGroups > AllGroups isNil ifTrue: [ AllGroups := Set new ]. > ^AllGroups! ! > > !Group class methodsFor: 'accessing' stamp: 'jau 3/10/2005 15:38'! > removeGroup: aGroup > self allGroups remove: aGroup! ! > > > !Group class methodsFor: 'examples' stamp: 'jau 3/10/2005 15:38'! > test > "Group test" > | john adminGroup | > > "1) creating a user" > john := User new name: 'John'. > User addUser: john. > > "2) creating a group" > adminGroup := Group new name: 'Administrator'. > Group removeGroup: adminGroup. > > "3) associating a user with a group" > adminGroup users add: john. > > "4) removing the association between a user and a group" > adminGroup users remove: john. > > "5) deleting a user" > User removeUser: john. > > "6) deleting a group" > Group removeGroup: adminGroup. > > "7) selecting users or groups based on simple criteria" > User allUsers select: [ :each | each name == 'John' ]. > Group allGroups select: [ :each | each name == 'Administrator' ].! ! > > Model subclass: #User > instanceVariableNames: 'name' > classVariableNames: 'AllUsers' > poolDictionaries: '' > category: 'Work-Groups'! > > !User methodsFor: 'accessing' stamp: 'jau 3/10/2005 15:07'! > name > ^name! ! > > !User methodsFor: 'accessing' stamp: 'jau 3/10/2005 15:07'! > name: aString > name := aString! ! > > "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "! > > User class > instanceVariableNames: ''! > > !User class methodsFor: 'accessing' stamp: 'jau 3/10/2005 15:29'! > addUser: aUser > self allUsers add: aUser! ! > > !User class methodsFor: 'accessing' stamp: 'jau 3/10/2005 15:08'! > allUsers > AllUsers isNil ifTrue: [ AllUsers := Set new ]. > ^AllUsers! ! > > !User class methodsFor: 'accessing' stamp: 'jau 3/10/2005 15:36'! > removeUser: aUser > Group allGroups do: [ :each | > (each containsUser: aUser) ifTrue: [ > self error: 'User is referenced by a group.' ] ]. > self allUsers remove: aUser.! ! > > Regards, > John >
On Thu, 10 Mar 2005 07:53:36 -0800, Costin Cozianu <c_cozianu@hotmail.com> wrote: >I have yet to see a OO programming language based solution in comparable >lines of code (which shows that the tools of the trade in SQL are pretty >high level stuff compared with the pointers and the arrays RCM was >talking about), and to make it thread safe would be even a hell of a lot >more work. > Probably because it doesnt exist. M2M relationships are generally modelled in RDB by the use of a third party such as a link table. In OO the concept doesn't exist as such. At best you'd have two collections in memory with a mechanism for navigating between each. Why you'd ever want to iterate over a set of objects is beyond me. In C++ we just use an Iterator, its nothing to do with the DB. However, its much easier to post an event and let the interested parties sort themselves out. You cannont and should not ever try and compare a data driven approach as used in an RDB to an encapsulated approach where actual data is irrelevant which is the focus of OO. Remember is OO you also work with behaviours, not just identity.
"Costin Cozianu" <c_cozianu@hotmail.com> wrote in message news:3996q3F5uitbpU1@individual.net... > Allegations have veen made recently (Application vs. Business Logic > thread) that only if we had enough peristent RAM so that we can get rid of > Oracle and its ilk, milk and honey will flow all across the OO land now > freed from Object Relational (Psychological) Impedance Mismatch. To make it a fair challenge I would also like to see a RDB implementation that doesn't use any RAM. SP
|
0 |
|
SP
3/11/2005 2:52:37 AM
On Wed, 09 Mar 2005 13:06:10 -0800, Costin Cozianu wrote: > Allegations have veen made recently (Application vs. Business Logic > thread) that only if we had enough peristent RAM so that we can get rid > of Oracle and its ilk, milk and honey will flow all across the OO land > now freed from Object Relational (Psychological) Impedance Mismatch. > > Claims have been handwaved across this newsgroups that core > functionality implemented by DBMS engines was not needed because it > would be trivially covered by the brave OO coders writing their ADTs on > a case by case basis. > > Since this is old news, I thought I refer those brave OO coders to > something I created specifically for such occasions: > > http://c2.com/cgi/wiki?ManyToManyChallenge > > I'm waiting to see how OO weenies out there put their code where their > mouth is. > > In particular I would stress the requirement that whatever class or > object (for object based, Java Script kind of guys) you create to manage > the many to many relationship , it should be usable from the calling > context without any fear of deadlock or spurious results in a > multi-threaded environment. Again, persistence is not an issue -- data > need not be persisted (imagine you had your nvram or whatever). OK, but let's make the challenge little more realistic: 1. Each user encapsulates a task running in parallel to others. 2. The user task: sleeps an arbitrary period of time from 1..10ms. undertakes one of the following actions at random: 2.a. Read Usenet (and post reply) 2.b. Post Usenet (new message) 2.c. Join a group (randomly) 2.d. Leave a group (randomly) 2.e. Create a new group 2.f. Change the profile (randomly) 2.g. Create another user The user profile determines the distribution of the probabilities over 2.a..g. Let's have three profiles Hardcore_Fan, Waver, Troll. After 1000 cycles a user task ends and so the user reaches Nirvana. 3. The Usenet is a blackboard of messages. When a user reads it, he does only unread messages. If the message is from him he ignores it. If it is from another user he posts either "cool" or "rubbish" depending on if the poster was from any of his groups. When he is not a member of any group he ignores the message. 4. Groups without users cease to exist. Show me SQL code, then I will post mine. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
mailbox2On Fri, 11 Mar 2005 02:52:37 GMT, "SP" <egatsecneserp(reverse)@hotmail.com> wrote: >To make it a fair challenge I would also like to see a RDB implementation >that doesn't use any RAM. What a nonsense! Regards
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote: >On Wed, 09 Mar 2005 13:06:10 -0800, Costin Cozianu wrote: > I like this new challenge, I think I will use it as an assignment for my students ! >OK, but let's make the challenge little more realistic: > >1. Each user encapsulates a task running in parallel to others. > ... > >3. The Usenet is a blackboard of messages. When a user reads it, he does >only unread messages. If the message is from him he ignores it. If it is >from another user he posts either "cool" or "rubbish" depending on if the >poster was from any of his groups. When he is not a member of any group he >ignores the message. Can you clarify here ? (too many "he" for the text to be clear). Moreover, if user A only reads and posts message from groups he has previously joined, obviously when user A reads a message M, M's poster should be from at least one of A's groups (unless M's poster has very recently left M's group)
FirstName.LastName7654On Fri, 11 Mar 2005 13:33:03 +0100, Remi Bastide wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
>
>>On Wed, 09 Mar 2005 13:06:10 -0800, Costin Cozianu wrote:
>>
> I like this new challenge, I think I will use it as an assignment for
> my students !
>
>>OK, but let's make the challenge little more realistic:
>>
>>1. Each user encapsulates a task running in parallel to others.
>>
> ..
>>
>>3. The Usenet is a blackboard of messages. When a user reads it, he does
>>only unread messages. If the message is from him he ignores it. If it is
>>from another user he posts either "cool" or "rubbish" depending on if the
>>poster was from any of his groups. When he is not a member of any group he
>>ignores the message.
>
> Can you clarify here ? (too many "he" for the text to be clear).
A user U can be a member of many or no group. So U.Gropus is the set of its
groups. A message M has the message author M.User. For simplicity when user
dies he first waits in the Purgatory, before the last message vanishes from
the blackboard. So read can be:
if not U.Groups is empty then
if M.User in any of U.Groups then
Post ">" & M.Text & New_Line & "Cool!";
else
Post ">" & M.Text & New_Line & "Rubbish!";
end if;
end if;
> Moreover, if user A only reads and posts message from groups he has
> previously joined, obviously when user A reads a message M, M's poster
> should be from at least one of A's groups (unless M's poster has very
> recently left M's group)
I meant not Usenet groups, but OO-fans, RDBMS-fans etc. (:-))
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Dmitry A. Kazakov wrote:
> On Wed, 09 Mar 2005 13:06:10 -0800, Costin Cozianu wrote:
>
>
>>Allegations have veen made recently (Application vs. Business Logic
>>thread) that only if we had enough peristent RAM so that we can get rid
>>of Oracle and its ilk, milk and honey will flow all across the OO land
>>now freed from Object Relational (Psychological) Impedance Mismatch.
>>
>>Claims have been handwaved across this newsgroups that core
>>functionality implemented by DBMS engines was not needed because it
>>would be trivially covered by the brave OO coders writing their ADTs on
>>a case by case basis.
>>
>>Since this is old news, I thought I refer those brave OO coders to
>>something I created specifically for such occasions:
>>
>>http://c2.com/cgi/wiki?ManyToManyChallenge
>>
>>I'm waiting to see how OO weenies out there put their code where their
>>mouth is.
>>
>>In particular I would stress the requirement that whatever class or
>>object (for object based, Java Script kind of guys) you create to manage
>>the many to many relationship , it should be usable from the calling
>>context without any fear of deadlock or spurious results in a
>>multi-threaded environment. Again, persistence is not an issue -- data
>>need not be persisted (imagine you had your nvram or whatever).
>
>
> OK, but let's make the challenge little more realistic:
>
> 1. Each user encapsulates a task running in parallel to others.
>
> 2. The user task:
>
> sleeps an arbitrary period of time from 1..10ms.
> undertakes one of the following actions at random:
>
> 2.a. Read Usenet (and post reply)
> 2.b. Post Usenet (new message)
> 2.c. Join a group (randomly)
> 2.d. Leave a group (randomly)
> 2.e. Create a new group
> 2.f. Change the profile (randomly)
> 2.g. Create another user
>
> The user profile determines the distribution of the probabilities over
> 2.a..g. Let's have three profiles Hardcore_Fan, Waver, Troll.
>
> After 1000 cycles a user task ends and so the user reaches Nirvana.
>
> 3. The Usenet is a blackboard of messages. When a user reads it, he does
> only unread messages. If the message is from him he ignores it. If it is
> from another user he posts either "cool" or "rubbish" depending on if the
> poster was from any of his groups. When he is not a member of any group he
> ignores the message.
>
> 4. Groups without users cease to exist.
>
> Show me SQL code, then I will post mine.
>
Your challenge is irrelevant as is contains the arbitrary constraint
that it has to be solved in SQL only. Make it Java + SQL or something
equivalent and one can easily spawn processes for each user and perform
the above actions by trivial SQL statements.
1.a -- retrieving messages by a reader
SELECT FROM messages WHERE group_id IN
(SELECT group_id from r_groups_users where user_id= :user_id)
2.a INSERT R_messages_users(msg_id,:user_id) VALUES (:msg_id, :user_id)
2.b INSERT INTO messages VALUES (...)
2.c INSERT INTO R_groups_users VALUES(:group_id, user_id)
2.d DELETE FROM R_groups_users where group_id= :group_id AND user_id=
:user_id
2.e INSERT INTO groups values (...)
2.f UPDATE users SET ... -- whatever profile values
2.g INSERT INTO users VALUES (...)
-- deleting groups without users
3. Delete from groups g WHERE NOT EXISTS
(select * from r_groups_users WHERE r.group_id= g.group_id)
Having said that, the challenge becomes rather boring and unchallenging
as there is no new insight to be gained from it. The host language will
provide the source of random data, spawn threads, etc. The SQL DBMS
will perform the above data manipulation operations ensuring safety and
consistency in the presence of concurrent access.
In the meantime I have yet to see some OO code that solves even my very
modest challenge.
On Fri, 11 Mar 2005 08:00:53 -0800, Costin Cozianu wrote: > Dmitry A. Kazakov wrote: >> On Wed, 09 Mar 2005 13:06:10 -0800, Costin Cozianu wrote: >> >>>Allegations have veen made recently (Application vs. Business Logic >>>thread) that only if we had enough peristent RAM so that we can get rid >>>of Oracle and its ilk, milk and honey will flow all across the OO land >>>now freed from Object Relational (Psychological) Impedance Mismatch. >>> >>>Claims have been handwaved across this newsgroups that core >>>functionality implemented by DBMS engines was not needed because it >>>would be trivially covered by the brave OO coders writing their ADTs on >>>a case by case basis. >>> >>>Since this is old news, I thought I refer those brave OO coders to >>>something I created specifically for such occasions: >>> >>>http://c2.com/cgi/wiki?ManyToManyChallenge >>> >>>I'm waiting to see how OO weenies out there put their code where their >>>mouth is. >>> >>>In particular I would stress the requirement that whatever class or >>>object (for object based, Java Script kind of guys) you create to manage >>>the many to many relationship , it should be usable from the calling >>>context without any fear of deadlock or spurious results in a >>>multi-threaded environment. Again, persistence is not an issue -- data >>>need not be persisted (imagine you had your nvram or whatever). >> >> OK, but let's make the challenge little more realistic: >> >> 1. Each user encapsulates a task running in parallel to others. >> >> 2. The user task: >> >> sleeps an arbitrary period of time from 1..10ms. >> undertakes one of the following actions at random: >> >> 2.a. Read Usenet (and post reply) >> 2.b. Post Usenet (new message) >> 2.c. Join a group (randomly) >> 2.d. Leave a group (randomly) >> 2.e. Create a new group >> 2.f. Change the profile (randomly) >> 2.g. Create another user >> >> The user profile determines the distribution of the probabilities over >> 2.a..g. Let's have three profiles Hardcore_Fan, Waver, Troll. >> >> After 1000 cycles a user task ends and so the user reaches Nirvana. >> >> 3. The Usenet is a blackboard of messages. When a user reads it, he does >> only unread messages. If the message is from him he ignores it. If it is >> from another user he posts either "cool" or "rubbish" depending on if the >> poster was from any of his groups. When he is not a member of any group he >> ignores the message. >> >> 4. Groups without users cease to exist. >> >> Show me SQL code, then I will post mine. > > Your challenge is irrelevant as is contains the arbitrary constraint > that it has to be solved in SQL only. Wasn't that your point? > Make it Java + SQL or something > equivalent and one can easily spawn processes for each user and perform > the above actions by trivial SQL statements. > > 1.a -- retrieving messages by a reader > SELECT FROM messages WHERE group_id IN > (SELECT group_id from r_groups_users where user_id= :user_id) > 2.a INSERT R_messages_users(msg_id,:user_id) VALUES (:msg_id, :user_id) > 2.b INSERT INTO messages VALUES (...) > 2.c INSERT INTO R_groups_users VALUES(:group_id, user_id) > 2.d DELETE FROM R_groups_users where group_id= :group_id AND user_id= >:user_id > 2.e INSERT INTO groups values (...) > 2.f UPDATE users SET ... -- whatever profile values > 2.g INSERT INTO users VALUES (...) > > -- deleting groups without users > 3. Delete from groups g WHERE NOT EXISTS > (select * from r_groups_users WHERE r.group_id= g.group_id) > > Having said that, the challenge becomes rather boring and unchallenging > as there is no new insight to be gained from it. The host language will > provide the source of random data, spawn threads, etc. Are such trivial things impossible in the Great Relational Paradigm? No pseudo-random generators? No any multi-tasking? I'm slightly disappointed. (:-)) > The SQL DBMS > will perform the above data manipulation operations ensuring safety and > consistency in the presence of concurrent access. You can't sell the above to a customer, can you? It should be a complete executable application. If that includes a Sun cluster + Java + Oracle, let it be so. (Though the customer might have some financial constraints, but that's aside.) > In the meantime I have yet to see some OO code that solves even my very > modest challenge. Your code is not yet a ready-to-use software. You have provided only a DB structure. It is like a UML diagram, nice to have, but hard to sell... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
Responding to Cozianu... >>> http://c2.com/cgi/wiki?ManyToManyChallenge >> >> >> >> I think it's a straw man challenge. > > > If it was a straw man somebody would know it down by code. Probably you > meant Red Herring No, I meant straw man. From Webster's unabridged: 1. a bundle of straw made to look like a man, as a scarecrow. 2. a person of little importance; a nonentity. 3. a weak argument or opposing view set up by a politician, debater, etc. so that he may attack it and gain an easy, showy victory. 4. a person use to disguise another's intentions, activities, etc.; blind. > >> The challenge is to emulate data storage techniques and technologies >> when implementing from scratch using OO construction. > > > Where do you see "storage". I explicitly mentioned that persistence of > that data is of no concern at all in the challenge. You constrained the challenge to a particular design for data access that parallels your SQL implementation and is only used in an RDB storage context. IOW, your challenge describes the requirements for implementing part of a SQL driver. That means the OO solution must explicitly implement the functionality implemented /in/ a SQL driver to handle your constraints. ************* There is nothing wrong with me that could not be cured by a capful of Drano. H. S. Lahman hsl@pathfindermda.com Pathfinder Solutions -- Put MDA to Work http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman (888)OOA-PATH
H. S. Lahman wrote: > Responding to Cozianu... > >>>> http://c2.com/cgi/wiki?ManyToManyChallenge >>> >>> >>> >>> >>> I think it's a straw man challenge. >> >> >> >> If it was a straw man somebody would know it down by code. Probably >> you meant Red Herring > > > No, I meant straw man. From Webster's unabridged: > > 1. a bundle of straw made to look like a man, as a scarecrow. > > 2. a person of little importance; a nonentity. > > 3. a weak argument or opposing view set up by a politician, debater, > etc. so that he may attack it and gain an easy, showy victory. > > 4. a person use to disguise another's intentions, activities, etc.; blind. > So the definition does not apply to my challenge. I did not construct a clumsy OO solution to the challenge so that I would knock it down. That would have been a straw man. I just presented a problem, that is seemingly natural and developers encounter such things (many to many relationship) countless times in all kinds of apps. >> >>> The challenge is to emulate data storage techniques and technologies >>> when implementing from scratch using OO construction. >> >> >> >> Where do you see "storage". I explicitly mentioned that persistence of >> that data is of no concern at all in the challenge. > > > You constrained the challenge to a particular design for data access > that parallels your SQL implementation and is only used in an RDB > storage context. Nonsense. The constraints are natural and come from the nature of the beast. What exactly is the constraint that makes approaching the solution from an OO point of view awkward ? I'll tell you what: the concurrency and safety aspect of it. But tons of software developed nowadays need to handle concurrency and the need for safety is obvious. So if you accuse that I put these constraints in there just to make OO solutions inadequate then an OO *only* solution will be inadequate in addressing a lot of real software out there, because lots of real software out there has these constraints. It's not something that I arbitrarily throw into the mix. > IOW, your challenge describes the requirements for > implementing part of a SQL driver. That means the OO solution must > explicitly implement the functionality implemented /in/ a SQL driver to > handle your constraints. > > Nonsense. Nothing in the requirements of my challenge define a SQL driver. That SQL DBMSes deal with concurrency and safety is only natural. But if you say that whenever somebody adds concurrency and safety to the mix, one defines requirements for implementing a SQL based solutinj, you just prove my point.
Dmitry A. Kazakov wrote: >>Make it Java + SQL or something >>equivalent and one can easily spawn processes for each user and perform >>the above actions by trivial SQL statements. >> >>1.a -- retrieving messages by a reader >> SELECT FROM messages WHERE group_id IN >> (SELECT group_id from r_groups_users where user_id= :user_id) >>2.a INSERT R_messages_users(msg_id,:user_id) VALUES (:msg_id, :user_id) >>2.b INSERT INTO messages VALUES (...) >>2.c INSERT INTO R_groups_users VALUES(:group_id, user_id) >>2.d DELETE FROM R_groups_users where group_id= :group_id AND user_id= >>:user_id >>2.e INSERT INTO groups values (...) >>2.f UPDATE users SET ... -- whatever profile values >>2.g INSERT INTO users VALUES (...) >> >>-- deleting groups without users >>3. Delete from groups g WHERE NOT EXISTS >> (select * from r_groups_users WHERE r.group_id= g.group_id) >> >>Having said that, the challenge becomes rather boring and unchallenging >>as there is no new insight to be gained from it. The host language will >>provide the source of random data, spawn threads, etc. > > > Are such trivial things impossible in the Great Relational Paradigm? No > pseudo-random generators? No any multi-tasking? I'm slightly disappointed. > (:-)) > > Now I am sorry to say Dmitry but you are simply trolling. Who lead you to believe that the "Great Relational Paradigm" was good for writing pseudo-random generators ? It was certainly not me, and with your experience you should have known better. That's why such crappy arguments are a form of trolling. It was *your* thesis that with such great advancements in RAM technology and OO and whatever, the SQL DBMS becomes a redundant element in the picture of a whole software system cause we don't need persistency no more, it'll be done automatically. So I say fine, let's get persistence out of the picture, let's get SQL as well out of the picture, here's a problem, now solve it. At no point did I imply that the alternative to say an ADA only solution was a SQL onl solution. The current status-quo in a lot of systems is a combination of host-language + db driver + SQL DBMS, which proves good enough for tons of software out there. So your knoking down a SQL only solution is useless conversational chaff >>The SQL DBMS >>will perform the above data manipulation operations ensuring safety and >>consistency in the presence of concurrent access. > > > You can't sell the above to a customer, can you? It should be a complete > executable application. If that includes a Sun cluster + Java + Oracle, let > it be so. (Though the customer might have some financial constraints, but > that's aside.) > Non-sense. PostgreSQL and a Linux server with java or what have you will do just fine, these days. > >>In the meantime I have yet to see some OO code that solves even my very >>modest challenge. > > > Your code is not yet a ready-to-use software. You have provided only a DB > structure. It is like a UML diagram, nice to have, but hard to sell... > Well, I left the Java glue part as an exercise for the reader because it is trivial and boring, so it makes no sense to waste my time writing it in order to keep you happy. So now let me see the OO code for my simple challenge. I contend that in the absence of a DBMS support to deal with issues of consistency and concurrency (as well as for other things like index bookkeeping), the OO code is anything but trivial. In fact it is seemingly so complex that nobody came close to approaching it, and even you try to handwave around it.
Costin Cozianu wrote:
> However, the essential part is this: your code is good for single
> threaded environments only.
You must have missed the part about running this code in Gemstone.
Doing that gives me a "distributed, server-based, multiuser,
transactional Smalltalk runtime system". I'm pretty sure just about
any commercial OODBMS could handle your challenge.
> After all these are added I think you are already at least triple the
> lines of code in the SQL setup.
Actually, I'll have 2.5 times the code. And you would have a big win
if your user interface consists of ISQL. But in the real world, I
actually have to build a program with a UI and business logic.
Let's extend your example. You have to build a group maintenance
screen. It's a window with two list boxes, one side contains all the
groups, the other contains all the users. Select a group and all the
users in the group are highlighted. You can add users by highlighting
them or remove them by unhighlighting them. A delete button removes
the highlighted group.
Here's what the Smalltalk code (minus GUI layout) might look like:
groupsList model: (ListModel on: Group allGroups).
groupsList onSelection: [ :group |
userList clearSelections.
userList setSelections: group users ].
userList model: (ListModel on: User allUsers).
userList onSelection: [ :user |
groupList selection addUser: user ].
userList onDeselection: [ :user |
groupList selection removeUser: user ].
deleteButton onClick: [ Group removeGroup: (groupList selection) ].
"this is what the Gemstone doc says I have to do..."
saveButton onClick: [ System commitTransaction ].
groupList select: (Group allGroups first).
Compare this to a DB RAD environment (PowerBuilder in this case):
window open event:
dw_group.setSQLSelect("select * from groups")
dw_group.retrieve()
dw_user.setSQLSelect("select * from users")
dw_group.retrieve()
ds_usergroup.setSQLSelect("select * from r_user_groups")
ds_usergroup.retrieve()
dw_group.selectRow(1, true)
onGroupSelectionChange(1)
function onGroupSelectionChange(int row):
dw_user.selectRow(0, false)
int groupId = dw_group.getItemNumber(1, "group_id")
ds_usergroup.setFilter("group_id = " + string(groupId))
ds_usergroup.filter()
for row = 1 to ds_usergroup.rowCount()
int userId = ds_usergroup.getItemNumber(row, "user_id")
int userRow = dw_user.find("user_id = " + string(userId), 0,
dw_user.rowCount())
dw_user.selectRow(userRow, true)
next
function onUserSelected(int row):
int groupId = dw_group.getItemNumber(dw_group.getSelectedRow(),
"group_id")
int userId = dw_user.getItemNumber(row, "user_id")
int row = ds_usergroup.insertRow(0)
ds_userGroup.setItem(row, "user_id", userId)
ds_userGroup.setItem(row, "group_id", groupId)
function onUserUnselected(int row):
int groupId = dw_group.getItemNumber(dw_group.getSelectedRow(),
"group_id")
int userId = dw_user.getItemNumber(row, "user_id")
int row = ds_usergroup.find("user_id = " + string(userid) + " and
group_id = " + string(groupid), 0, ds_usergroup.rowCount())
ds_usergroup.deleteRow(row)
delete button clicked event:
int row = dw_group.getSelectedRow(0)
// I'll assume group_ids are autogenerated so we don't need
// to clear the matching groups from the ds_userGroup datastore
dw_group.deleteRow(row)
save button clicked event:
// ignoring error handling code for now...
ds_userGroup.update(false, false)
dw_group.update(false, false)
commit;
Now imagine a real world example where I have an invoice screen that
accesses 20 - 30 tables.
The PowerBuilder application I work on has about 400 tables and 700
KLOC. Only about 10% of that is SQL; most of that is selects since
PowerBuilder can generate the insert/update/deletes on the fly. Maybe
another 20% is window and report layout code. The rest is business
logic code and a good chunk of that is the kind of crap you see in my
example; lots of code to navigate thru result sets in on-screen
datawindows and off-screen datastores.
Now imaging if I rewrite that 70% in an object oriented style and bind
objects to the GUI elements. That will save me quite a bit of code,
don't you think? If we take it a step farther and use an ODBMS, that
10% of the application that is data access gets trimmed down quite a
bit also (compare 'Invoice lookup: anId' to all the SQL required to
load an invoice and it's related data across 20 some tables).
Regards,
John
(* Let's extend your example. You have to build a group maintenance screen. It's a window with two list boxes, one side contains all the groups, the other contains all the users. Select a group and all the users in the group are highlighted. You can add users by highlighting them or remove them by unhighlighting them. A delete button removes the highlighted group. *) Personally, I think I would explore different UI approaches to that if there are a lot of users. If there are only a few users, then a grid might make for an interesting interface, with users on one axis and groups on another. -T-
topmindJohn Urberg wrote:
> Costin Cozianu wrote:
>
>>However, the essential part is this: your code is good for single
>>threaded environments only.
>
>
> You must have missed the part about running this code in Gemstone.
> Doing that gives me a "distributed, server-based, multiuser,
> transactional Smalltalk runtime system". I'm pretty sure just about
> any commercial OODBMS could handle your challenge.
>
>
No, I haven't missed that. It's just I haven't heard such a case that
you just write your code as if you're running in Squeak single threaded
only, and then you just deploy on a Smalltalk Vm and you're ready. But
then what do I know ?
As for your RAD example: I have 2 objections:
1) I couldn't have thought of a worse UI
2) Your PowerBuilder code does look way too verbose, but then I only
have experience with Delphi as a RAD environemnt, where a Master-Detail
views can be set in no time and with little or no code at all.
Even your UI model with selecting items would be in Java or Delphi
something quite trivial. The main problem I see in your PowerBuilder
code is that selection is modeled only by integers and that's a problem
with the design of the PowerBuilder framework not with having to access
the database.
>>After all these are added I think you are already at least triple the
>
>
>>lines of code in the SQL setup.
>
>
> Actually, I'll have 2.5 times the code. And you would have a big win
> if your user interface consists of ISQL. But in the real world, I
> actually have to build a program with a UI and business logic.
>
> Let's extend your example. You have to build a group maintenance
> screen. It's a window with two list boxes, one side contains all the
> groups, the other contains all the users. Select a group and all the
> users in the group are highlighted. You can add users by highlighting
> them or remove them by unhighlighting them. A delete button removes
> the highlighted group.
>
> Here's what the Smalltalk code (minus GUI layout) might look like:
>
> groupsList model: (ListModel on: Group allGroups).
> groupsList onSelection: [ :group |
> userList clearSelections.
> userList setSelections: group users ].
>
> userList model: (ListModel on: User allUsers).
> userList onSelection: [ :user |
> groupList selection addUser: user ].
> userList onDeselection: [ :user |
> groupList selection removeUser: user ].
>
> deleteButton onClick: [ Group removeGroup: (groupList selection) ].
>
> "this is what the Gemstone doc says I have to do..."
> saveButton onClick: [ System commitTransaction ].
>
> groupList select: (Group allGroups first).
>
> Compare this to a DB RAD environment (PowerBuilder in this case):
>
> window open event:
> dw_group.setSQLSelect("select * from groups")
> dw_group.retrieve()
> dw_user.setSQLSelect("select * from users")
> dw_group.retrieve()
> ds_usergroup.setSQLSelect("select * from r_user_groups")
> ds_usergroup.retrieve()
> dw_group.selectRow(1, true)
> onGroupSelectionChange(1)
>
> function onGroupSelectionChange(int row):
> dw_user.selectRow(0, false)
> int groupId = dw_group.getItemNumber(1, "group_id")
> ds_usergroup.setFilter("group_id = " + string(groupId))
> ds_usergroup.filter()
> for row = 1 to ds_usergroup.rowCount()
> int userId = ds_usergroup.getItemNumber(row, "user_id")
> int userRow = dw_user.find("user_id = " + string(userId), 0,
> dw_user.rowCount())
> dw_user.selectRow(userRow, true)
> next
>
> function onUserSelected(int row):
> int groupId = dw_group.getItemNumber(dw_group.getSelectedRow(),
> "group_id")
> int userId = dw_user.getItemNumber(row, "user_id")
> int row = ds_usergroup.insertRow(0)
> ds_userGroup.setItem(row, "user_id", userId)
> ds_userGroup.setItem(row, "group_id", groupId)
>
> function onUserUnselected(int row):
> int groupId = dw_group.getItemNumber(dw_group.getSelectedRow(),
> "group_id")
> int userId = dw_user.getItemNumber(row, "user_id")
> int row = ds_usergroup.find("user_id = " + string(userid) + " and
> group_id = " + string(groupid), 0, ds_usergroup.rowCount())
> ds_usergroup.deleteRow(row)
>
> delete button clicked event:
> int row = dw_group.getSelectedRow(0)
> // I'll assume group_ids are autogenerated so we don't need
> // to clear the matching groups from the ds_userGroup datastore
> dw_group.deleteRow(row)
>
> save button clicked event:
> // ignoring error handling code for now...
> ds_userGroup.update(false, false)
> dw_group.update(false, false)
> commit;
>
> Now imagine a real world example where I have an invoice screen that
> accesses 20 - 30 tables.
>
> The PowerBuilder application I work on has about 400 tables and 700
> KLOC. Only about 10% of that is SQL; most of that is selects since
> PowerBuilder can generate the insert/update/deletes on the fly. Maybe
> another 20% is window and report layout code. The rest is business
> logic code and a good chunk of that is the kind of crap you see in my
> example; lots of code to navigate thru result sets in on-screen
> datawindows and off-screen datastores.
>
> Now imaging if I rewrite that 70% in an object oriented style and bind
> objects to the GUI elements. That will save me quite a bit of code,
> don't you think?
No, I don't think. I think you'd be way more productive if you changed
from PowerBuilder to Delphi who has a much better designed RAD framework
(VCL library) so you wouln't have to write the kind of things that I see
above.
I've written an accounting system in Delphi with Postgres and I have no
idea of the kind of code you're talking about. Because controls were
bound directly to tables, views, and SQL query data sources the most
code I needed to do on occasion was to bind a parameter or to alter the
SQL string of a data source.
> If we take it a step farther and use an ODBMS, that
> 10% of the application that is data access gets trimmed down quite a
> bit also (compare 'Invoice lookup: anId' to all the SQL required to
> load an invoice and it's related data across 20 some tables).
>
No, I don't see how maintaining all the relationships that Invoice has
with other entities is easier in Smalltalk then in SQL. I'd think that
your Invoice implementation would be quite more verbose, because I have
yet to see a complete solution to the User - Group challenge.
> Regards,
> John
>
best,
Costin
On 11 Mar 2005 11:03:44 -0800, "John Urberg" <jurberg@gmail.com> wrote: > But in the real world, I >actually have to build a program with a UI and business logic. If the business logic is enforced by the DBMS you don't need to build a program with business logic. That's evident. >Let's extend your example. You have to build a group maintenance >screen. It's a window with two list boxes, one side contains all the >groups, the other contains all the users. Select a group and all the >users in the group are highlighted. You can add users by highlighting >them or remove them by unhighlighting them. A delete button removes >the highlighted group. What an odd interface! I could create the typical two editable grids, master-detail form with navigation/delete button bars, typing 0 lines of Delphi code. >The rest is business >logic code and a good chunk of that is the kind of crap you see in my >example; lots of code to navigate thru result sets in on-screen >datawindows and off-screen datastores. Such crap was presentation logic and not business logic. >Now imaging if I rewrite that 70% in an object oriented style and bind >objects to the GUI elements. That will save me quite a bit of code, >don't you think? You could save a lot more using a decent RAD tool properly. But that is completely irrelevant to the discussion. > If we take it a step farther and use an ODBMS It is highly probable that the (real) business logic code size would suffer an orders of magnitude expansion. OODBMS's are very primitive compared to RDBMS's. Although is definitely better to use an OODBMS than to manage the database directly from the applications. Network DBMS's (and OODBMS's are network DBMS's) were an intermediate evolutionary step between file processing and RDBMS's. Now they are completely obsolete. Regards
On Fri, 11 Mar 2005 11:01:20 -0800, Costin Cozianu wrote: > Dmitry A. Kazakov wrote: > >>>Make it Java + SQL or something >>>equivalent and one can easily spawn processes for each user and perform >>>the above actions by trivial SQL statements. >>> >>>1.a -- retrieving messages by a reader >>> SELECT FROM messages WHERE group_id IN >>> (SELECT group_id from r_groups_users where user_id= :user_id) >>>2.a INSERT R_messages_users(msg_id,:user_id) VALUES (:msg_id, :user_id) >>>2.b INSERT INTO messages VALUES (...) >>>2.c INSERT INTO R_groups_users VALUES(:group_id, user_id) >>>2.d DELETE FROM R_groups_users where group_id= :group_id AND user_id= >>>:user_id >>>2.e INSERT INTO groups values (...) >>>2.f UPDATE users SET ... -- whatever profile values >>>2.g INSERT INTO users VALUES (...) >>> >>>-- deleting groups without users >>>3. Delete from groups g WHERE NOT EXISTS >>> (select * from r_groups_users WHERE r.group_id= g.group_id) >>> >>>Having said that, the challenge becomes rather boring and unchallenging >>>as there is no new insight to be gained from it. The host language will >>>provide the source of random data, spawn threads, etc. >> >> >> Are such trivial things impossible in the Great Relational Paradigm? No >> pseudo-random generators? No any multi-tasking? I'm slightly disappointed. >> (:-)) > > Now I am sorry to say Dmitry but you are simply trolling. > > Who lead you to believe that the "Great Relational Paradigm" was good > for writing pseudo-random generators ? It was certainly not me, and with > your experience you should have known better. That's why such crappy > arguments are a form of trolling. So if we are in agreement that raw SQL does not qualify, then let me insist that you have to present *complete* code. To avoid further misunderstanding. That does not mean that you have to present the source code of OS, Oracle or any library you are going to use. It only means that you have to show a compilable code of the application that solves the challenge and is linkable against the libraries you use. Is that too much to ask for? > It was *your* thesis that with such great advancements in RAM technology > and OO and whatever, the SQL DBMS becomes a redundant element in the > picture of a whole software system cause we don't need persistency no > more, it'll be done automatically. Correction, that was Robert Martin, but I fully agree with him. The notion of persistency is a relict of the era when distributed systems were considered as an unstructured bunch of hosts. In future systems nothing will persist, but only exist. > So I say fine, let's get persistence out of the picture, let's get SQL > as well out of the picture, here's a problem, now solve it. At no point > did I imply that the alternative to say an ADA only solution was a SQL > onl solution. The current status-quo in a lot of systems is a > combination of host-language + db driver + SQL DBMS, which proves good > enough for tons of software out there. > > So your knoking down a SQL only solution is useless conversational chaff I didn't require that. >>>The SQL DBMS >>>will perform the above data manipulation operations ensuring safety and >>>consistency in the presence of concurrent access. >> >> You can't sell the above to a customer, can you? It should be a complete >> executable application. If that includes a Sun cluster + Java + Oracle, let >> it be so. (Though the customer might have some financial constraints, but >> that's aside.) > > Non-sense. PostgreSQL and a Linux server with java or what have you > will do just fine, these days. Excellent, go on! >>>In the meantime I have yet to see some OO code that solves even my very >>>modest challenge. >> >> Your code is not yet a ready-to-use software. You have provided only a DB >> structure. It is like a UML diagram, nice to have, but hard to sell... > > Well, I left the Java glue part as an exercise for the reader because it > is trivial and boring, so it makes no sense to waste my time writing it > in order to keep you happy. It is no less trivial than to implement the challenge using any available component library and either an OO language that directly supports multitasking or one that uses OS primitives. > So now let me see the OO code for my simple challenge. I contend that in > the absence of a DBMS support to deal with issues of consistency and > concurrency (as well as for other things like index bookkeeping), the OO > code is anything but trivial. In fact it is seemingly so complex that > nobody came close to approaching it, and even you try to handwave around it. Not at all. The code in Ada 95 would be very simple and clean. Concurrency is not an issue, a protected object solves that trivially. Consistency is not an issue either, users and groups will be GC objects collected using reference counting. The component library handles that. What else? Sets of objects and two string maps? That is four instantiations from the same library ten lines of the source code. Done. Again I am ready to present the code if we agree on the details of the challenge. But I insist that the code has to be complete and the result be an executable ready to run. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
> So now let me see the OO code for my simple challenge. I contend that in > the absence of a DBMS support to deal with issues of consistency and > concurrency (as well as for other things like index bookkeeping), the OO > code is anything but trivial. In fact it is seemingly so complex that > nobody came close to approaching it, and even you try to handwave around it. I have to agree with you after reading the entire tread you have a valid point. I personally use RDMS for many to many. I write OO code, but not every freaking thing is an object. Or can be. IMHO not *every* business problem can be modeled or solved using *only* oop practices *efficiently*. Jason...
|
|
0 |
|
Jason
3/11/2005 9:21:13 PM
Dmitry A. Kazakov wrote: >>> > > So if we are in agreement that raw SQL does not qualify, then let me insist > that you have to present *complete* code. > > To avoid further misunderstanding. That does not mean that you have to > present the source code of OS, Oracle or any library you are going to use. > It only means that you have to show a compilable code of the application > that solves the challenge and is linkable against the libraries you use. Is > that too much to ask for? > Well, yes, because it's boring code and presents no insight into the topic we are discussing. And any software engineer worht his title would know what we're talking about so what;s the benefit in presenting such code ? If you convince me that there is, or you bet your reputation that the code you asked me to present is non-trivial and interesting in some kind of aspect, then maybe I'd consider. > >>It was *your* thesis that with such great advancements in RAM technology >>and OO and whatever, the SQL DBMS becomes a redundant element in the >>picture of a whole software system cause we don't need persistency no >>more, it'll be done automatically. > > > Correction, that was Robert Martin, but I fully agree with him. The notion > of persistency is a relict of the era when distributed systems were > considered as an unstructured bunch of hosts. In future systems nothing > will persist, but only exist. > Fine. Your claiming that does not an argument make. >>Well, I left the Java glue part as an exercise for the reader because it >>is trivial and boring, so it makes no sense to waste my time writing it >>in order to keep you happy. > > > It is no less trivial than to implement the challenge using any available > component library and either an OO language that directly supports > multitasking or one that uses OS primitives. > > Nonsense. The existing OO components support multi-tasking in the sense of spwaning threads and making easy for developers to aquire different kinds of locks, which gives developer enough ropes to shoot themselves in the foot (either deadlock in case they lock too much or corrupt data ). In comparison the SQL DBMS paradigm wraps database access in a transaction, aquires *all* needed locks on behalf of the programmer *correctly* without the programmer having to specify, it does even more by ensuring such things as serialization consistency, and in case that concurrent access patterns on behalf of different users lead to deadlock, it rolls back one of the transaction leaving both the system and the data in a safe state. So all you have to do in a host language while using SQL would be connection.executeStatement(sql) or something similar. Now if you present me the component libraries/language constructs out there that directly support this functionality, I'll agree that using them is trivial. Nevermind that merely writing the single threaded code that maintains indexes (hashmaps, trees, etc) in order, in the presence of updates to an object model is more useless boredom than any thing I can imagine and a SQL database will give you that for free.
Costin Cozianu wrote: > No, I haven't missed that. It's just I haven't heard such a case that > you just write your code as if you're running in Squeak single threaded > only, and then you just deploy on a Smalltalk Vm and you're ready. But > then what do I know ? >From what I understand, folks usually develop in VisualWorks and then deploy to Gemstone. I believe the only change in my code would be to use one of Gemstone's collection classes in allUsers and allGroups. > 1) I couldn't have thought of a worse UI <snip> > I've written an accounting system in Delphi with Postgres and I have no > idea of the kind of code you're talking about. Because controls were > bound directly to tables, views, and SQL query data sources the most > code I needed to do on occasion was to bind a parameter or to alter the > SQL string of a data source. That explains alot. If you can build your application with databound controls and SQL, more power to you. I've done it that way in the past in PowerBuilder (and you can do it much faster in PowerBuilder than in Delphi by the way), but the current application I work on doesn't fit in to the standard CRUD type of application. > No, I don't see how maintaining all the relationships that Invoice has > with other entities is easier in Smalltalk then in SQL. I'd think that > your Invoice implementation would be quite more verbose, because I have > yet to see a complete solution to the User - Group challenge. No, I don't suppose you would...but I suspect we are talking about different beasts. Let me know what I've missed in my Smalltalk interpretation of your User - Group challenge. Running it in Gemstone handles all the multi user issues. Is there anything else besides the reference to groups in User? Regards, John
Jason Hawryluk wrote: >>So now let me see the OO code for my simple challenge. I contend that in >>the absence of a DBMS support to deal with issues of consistency and >>concurrency (as well as for other things like index bookkeeping), the OO >>code is anything but trivial. In fact it is seemingly so complex that >>nobody came close to approaching it, and even you try to handwave around > > it. > > I have to agree with you after reading the entire tread you have a valid > point. He is comparing a relational database, and sql to a programming paridigm which isn't a valid comparison. In many ways this is like comparing a hard disk to assembly language. Storage is used to persist information, a programming language is used to process it. His solution isn't complete without some code in a programming language so how does that invalidate any language? SQL is useful but don't expect it to replace programming languages any time soon! :-) Jeff Brooks
John Urberg wrote: > Costin Cozianu wrote: > >>No, I haven't missed that. It's just I haven't heard such a case that >>you just write your code as if you're running in Squeak single > > threaded > >>only, and then you just deploy on a Smalltalk Vm and you're ready. > > But > >>then what do I know ? > > >>From what I understand, folks usually develop in VisualWorks and then > deploy to Gemstone. I believe the only change in my code would be to > use one of Gemstone's collection classes in allUsers and allGroups. > Can you refer me to their model for dealing with concurrency and transactions ?
"Alfredo Novoa" <alfredo_novoa@hotmail.com> wrote in message news:f6133118ldn1ircacqeiu9vlui05kh1b7g@4ax.com... > On Fri, 11 Mar 2005 02:52:37 GMT, "SP" > <egatsecneserp(reverse)@hotmail.com> wrote: > >>To make it a fair challenge I would also like to see a RDB implementation >>that doesn't use any RAM. > > > What a nonsense! > Exactly my point!
|
|
0 |
|
SP
3/12/2005 3:17:23 AM
> He is comparing a relational database, and sql > to a programming paridigm which isn't a valid > comparison. Although it is not a one-to-one overlap, relational and OO *do* tend to conflict with each other in many areas. They both fight over how noun attributes and relationships betwen nouns are managed. Relational also "centralizes" and standardizes collection-oriented behavior, while OO tends to let or want each object/class to handle it's own via behavioral interfaces. Collection handling is outside-in in relational and inside-out in OO. (These are perhaps overgeneralizations or oversimplifications, but generally true in my observation.) -T-
On Fri, 11 Mar 2005 13:37:21 -0800, Costin Cozianu wrote:
> Dmitry A. Kazakov wrote:
>>
>>>Well, I left the Java glue part as an exercise for the reader because it
>>>is trivial and boring, so it makes no sense to waste my time writing it
>>>in order to keep you happy.
>>
>> It is no less trivial than to implement the challenge using any available
>> component library and either an OO language that directly supports
>> multitasking or one that uses OS primitives.
>
> Nonsense. The existing OO components support multi-tasking in the sense
> of spwaning threads and making easy for developers to aquire different
> kinds of locks, which gives developer enough ropes to shoot themselves
> in the foot (either deadlock in case they lock too much or corrupt data ).
I would use Ada 95. It has no problems with all that. It is as simple as:
protected type Service is
procedure Create (Name : String; ID : out User);
procedure Create (Name : String; ID : out Group);
procedure Delete (ID : in out User);
procedure Delete (ID : in out Group);
procedure Join (Member : User; To : in out Group);
procedure Leave (Member : User; From : in out Group);
function Find (Name : String) return User;
function Find (Name : String) return Group;
function Is_In (Member : User; Club : Group) return Boolean;
private
...
end Service;
The above *cannot* deadlock, under no circumstances!
But even in C++ the above will be not very difficult to implement:
void Service::Create (const char * Name, User ID)
{
Locker Lock (&Mutex);
... // Safe access
}
It is a sample from our commercial component library for C++ we are using
when a customer requires C++ . This also cannot deadlock as long as only
one mutex is taken at a time.
> In comparison the SQL DBMS paradigm wraps database access in a
> transaction, aquires *all* needed locks on behalf of the programmer
> *correctly* without the programmer having to specify, it does even more
> by ensuring such things as serialization consistency, and in case that
> concurrent access patterns on behalf of different users lead to
> deadlock, it rolls back one of the transaction leaving both the system
> and the data in a safe state.
See the above. It is serialized, it is safe, it cannot deadlock.
> So all you have to do in a host language while using SQL would be
> connection.executeStatement(sql)
> or something similar.
And above will be:
Context.Join (A_User, A_Group);
> Now if you present me the component libraries/language constructs out
> there that directly support this functionality, I'll agree that using
> them is trivial.
It is.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
On Sat, 12 Mar 2005 03:17:23 GMT, "SP" <egatsecneserp(reverse)@hotmail.com> wrote: >"Alfredo Novoa" <alfredo_novoa@hotmail.com> wrote in message >news:f6133118ldn1ircacqeiu9vlui05kh1b7g@4ax.com... >> On Fri, 11 Mar 2005 02:52:37 GMT, "SP" >> <egatsecneserp(reverse)@hotmail.com> wrote: >> >>>To make it a fair challenge I would also like to see a RDB implementation >>>that doesn't use any RAM. >> >> >> What a nonsense! >> > >Exactly my point! The point you missed. Regards
On Fri, 11 Mar 2005 13:37:21 -0800, Costin Cozianu <c_cozianu@hotmail.com> wrote: >So all you have to do in a host language while using SQL would be > connection.executeStatement(sql) >or something similar. Although we would do that a lot better. >Nevermind that merely writing the single threaded code that maintains >indexes (hashmaps, trees, etc) in order, in the presence of updates to >an object model is more useless boredom than any thing I can imagine The problem is that many simple minds might find all that as very enjoyable. Regards
Dmitry A. Kazakov wrote:
> On Fri, 11 Mar 2005 13:37:21 -0800, Costin Cozianu wrote:
>
>
>>Dmitry A. Kazakov wrote:
>>
>>>>Well, I left the Java glue part as an exercise for the reader because it
>>>>is trivial and boring, so it makes no sense to waste my time writing it
>>>>in order to keep you happy.
>>>
>>>
>>>It is no less trivial than to implement the challenge using any available
>>>component library and either an OO language that directly supports
>>>multitasking or one that uses OS primitives.
>>
>>Nonsense. The existing OO components support multi-tasking in the sense
>>of spwaning threads and making easy for developers to aquire different
>>kinds of locks, which gives developer enough ropes to shoot themselves
>>in the foot (either deadlock in case they lock too much or corrupt data ).
>
>
> I would use Ada 95. It has no problems with all that. It is as simple as:
>
> protected type Service is
> procedure Create (Name : String; ID : out User);
> procedure Create (Name : String; ID : out Group);
> procedure Delete (ID : in out User);
> procedure Delete (ID : in out Group);
> procedure Join (Member : User; To : in out Group);
> procedure Leave (Member : User; From : in out Group);
> function Find (Name : String) return User;
> function Find (Name : String) return Group;
> function Is_In (Member : User; Club : Group) return Boolean;
> private
> ...
> end Service;
>
> The above *cannot* deadlock, under no circumstances!
>
> But even in C++ the above will be not very difficult to implement:
>
> void Service::Create (const char * Name, User ID)
> {
> Locker Lock (&Mutex);
> ... // Safe access
> }
>
> It is a sample from our commercial component library for C++ we are using
> when a customer requires C++ . This also cannot deadlock as long as only
> one mutex is taken at a time.
>
>
>>In comparison the SQL DBMS paradigm wraps database access in a
>>transaction, aquires *all* needed locks on behalf of the programmer
>>*correctly* without the programmer having to specify, it does even more
>>by ensuring such things as serialization consistency, and in case that
>>concurrent access patterns on behalf of different users lead to
>>deadlock, it rolls back one of the transaction leaving both the system
>>and the data in a safe state.
>
>
> See the above. It is serialized, it is safe, it cannot deadlock.
>
>
>>So all you have to do in a host language while using SQL would be
>> connection.executeStatement(sql)
>>or something similar.
>
>
> And above will be:
>
> Context.Join (A_User, A_Group);
>
>
>>Now if you present me the component libraries/language constructs out
>>there that directly support this functionality, I'll agree that using
>>them is trivial.
>
>
> It is.
>
If you can do nothing better than trolling this conversation is over.
"Alfredo Novoa" <alfredo_novoa@hotmail.com> wrote in message news:urk5319dagg8ad93qse3rlp5o5aqmk4elj@4ax.com... > On Sat, 12 Mar 2005 03:17:23 GMT, "SP" > <egatsecneserp(reverse)@hotmail.com> wrote: > >>"Alfredo Novoa" <alfredo_novoa@hotmail.com> wrote in message >>news:f6133118ldn1ircacqeiu9vlui05kh1b7g@4ax.com... >>> On Fri, 11 Mar 2005 02:52:37 GMT, "SP" >>> <egatsecneserp(reverse)@hotmail.com> wrote: >>> >>>>To make it a fair challenge I would also like to see a RDB >>>>implementation >>>>that doesn't use any RAM. >>> >>> >>> What a nonsense! >>> >> >>Exactly my point! > > The point you missed. > What point did I miss? The one that I pointed out? SP
|
|
0 |
|
SP
3/12/2005 3:50:44 PM
"Alfredo Novoa" <alfredo_novoa@hotmail.com> wrote in message news:urk5319dagg8ad93qse3rlp5o5aqmk4elj@4ax.com... > On Sat, 12 Mar 2005 03:17:23 GMT, "SP" > <egatsecneserp(reverse)@hotmail.com> wrote: > >>"Alfredo Novoa" <alfredo_novoa@hotmail.com> wrote in message >>news:f6133118ldn1ircacqeiu9vlui05kh1b7g@4ax.com... >>> On Fri, 11 Mar 2005 02:52:37 GMT, "SP" >>> <egatsecneserp(reverse)@hotmail.com> wrote: >>> >>>>To make it a fair challenge I would also like to see a RDB >>>>implementation >>>>that doesn't use any RAM. >>> >>> >>> What a nonsense! >>> >> >>Exactly my point! > > The point you missed. > I was making a little fun of the premise "that only if we had enough peristent RAM so that we can get rid of Oracle and its ilk" part of the original post. Regards, SP
|
|
0 |
|
SP
3/12/2005 4:16:35 PM
On Sat, 12 Mar 2005 02:12:07 GMT, Jeff Brooks <jeff_brooks@nospam.com> wrote: > Jason Hawryluk wrote: > >>>So now let me see the OO code for my simple challenge. I contend that in >>>the absence of a DBMS support to deal with issues of consistency and >>>concurrency (as well as for other things like index bookkeeping), the OO >>>code is anything but trivial. In fact it is seemingly so complex that >>>nobody came close to approaching it, and even you try to handwave around >> >> it. >> >> I have to agree with you after reading the entire tread you have a valid >> point. > > He is comparing a relational database, and sql to a programming paridigm > which isn't a valid comparison. > SQL is too low level for business applications. It deals with storage and persistance. As such, I keep it abstracted and away from my business objects, except through a defined interface to a storage mechanism abstraction. I try not to write my own low-level storage code, whether by "storage" I mean "read the rc file" or "SELECT yadayadayadqayada".
cdkrugAlfredo Novoa a �crit : > On 11 Mar 2005 11:03:44 -0800, "John Urberg" <jurberg@gmail.com> > wrote: > > >>But in the real world, I >>actually have to build a program with a UI and business logic. > > > If the business logic is enforced by the DBMS you don't need to build > a program with business logic. That's evident. And if the DBMS can't enforce the business logic, you need to build it into the program. That's evident too... (snip) > Network DBMS's (and OODBMS's are network DBMS's) were an intermediate > evolutionary step between file processing and RDBMS's. Now they are > completely obsolete. That's probably why with Zope's ZODB I can write a whole CMS without having to even bother about data storage. OODBMS have pros and cons. RDBMS have pros and cons. As usual, the *only* sensible line is to use the right tool for the job at hand. If you could stop making it a religious war...
bdesth.quelquechoseOn Sat, 12 Mar 2005 22:25:48 +0100, Bruno Desthuilliers <bdesth.quelquechose@free.quelquepart.fr> wrote: >> If the business logic is enforced by the DBMS you don't need to build >> a program with business logic. That's evident. > >And if the DBMS can't enforce the business logic, you need to build it >into the program. That's evident too... If something can not enforce the business logic then it is not a DBMS. >> Network DBMS's (and OODBMS's are network DBMS's) were an intermediate >> evolutionary step between file processing and RDBMS's. Now they are >> completely obsolete. > >That's probably why with Zope's ZODB I can write a whole CMS without >having to even bother about data storage. No, OODBMS's are not obsolete for that. >OODBMS have pros and cons. RDBMS have pros and cons. Of course, but if we compare OODBMS's to RDBMS's then OODBMS's don't have any technical pro. Regards
Costin Cozianu wrote: > >>From what I understand, folks usually develop in VisualWorks and then > > deploy to Gemstone. I believe the only change in my code would be to > > use one of Gemstone's collection classes in allUsers and allGroups. > > > > Can you refer me to their model for dealing with concurrency and > transactions ? You can download the documentation at http://www.gemstone.com/products/evaluation.php Regards, John
John Urberg wrote: > Costin Cozianu wrote: > >>>>From what I understand, folks usually develop in VisualWorks and > > then > >>>deploy to Gemstone. I believe the only change in my code would be > > to > >>>use one of Gemstone's collection classes in allUsers and allGroups. >>> >> >>Can you refer me to their model for dealing with concurrency and >>transactions ? > > > You can download the documentation at > http://www.gemstone.com/products/evaluation.php > > Regards, > John > Somebody else referred me to his pattern language related to it: http://wiki.cs.uiuc.edu/VisualWorks/DOWNLOAD/papers/int_vwgs2.zip , and I've been through the sport of downloading Gemstone products just to get to their documentation before. My opinion is that it is a waste of time, their way of dealing with concurrency being unnecessarily complex, shifting the difficulty to the developer's side and being far less comprehensive than the simple isolation level model provided by SQL standard. That's why I asked you if you had a more accessible and comprehensible treatment of the subject to see if there's anything that can change my mind. Thanks, Costin.
On Fri, 11 Mar 2005 11:01:20 -0800, Costin Cozianu <c_cozianu@hotmail.com> wrote: > Well, I left the Java glue part as an exercise for the reader because it > is trivial and boring, so it makes no sense to waste my time writing it > in order to keep you happy. This glue code is neverthless necessary for a meaningful direct comparison with a OO domain model API. For example how do you handle an attempt to breach your DB enforced contraints - do you allow the user to attempt the illegal operation on the DB and just bounce a DB level error straight back, or do you prehaps have an application layer which duplicates the constraints and issue a meaningfull error ?. Paul C.
|
|
0 |
|
paul
3/13/2005 2:45:23 PM
> SQL is too low level for business applications. It deals with storage > and persistance. SQL has nothing to do with storage or persistance. It is a query language. If you had a all-in-RAM solution, you would still need a query mechanism i business applications. > I keep it abstracted and away from my business objects Tables, foreign keys etc are business objects too. > I try not to write my own low-level storage code Low-level storage code is to handle files and primitive collection classes directly. SQL is a high-level language. > by "storage" I mean "read the rc file" or "SELECT yadayadayadqayada" You are comparing two completly different levels. If you are using SQL on the same level as direct file access, you will only use a fraction of the functionality in a relational database. Fredrik Bertilsson http://butler.sourceforge.net
fredrik_bertilssontopmind wrote: >>He is comparing a relational database, and sql >>to a programming paridigm which isn't a valid >>comparison. > > Although it is not a one-to-one overlap, relational and OO *do* tend to > conflict with each other in many areas. They both fight over how noun > attributes and relationships betwen nouns are managed. They do model things differently but you can't write software in sql. Saying SQL is better than OO is meaningless because sql is insuffient to build software with. This is an apples to oranges comparison. A better comparison is procedural, and OO paradigms. Perhaps looking at which types of language supports the relational model best might be a good idea. > Relational also "centralizes" and standardizes collection-oriented > behavior, while OO tends to let or want each object/class to handle > it's own via behavioral interfaces. Collection handling is outside-in > in relational and inside-out in OO. > > (These are perhaps overgeneralizations or oversimplifications, but > generally true in my observation.) Jeff Brooks
Costin Cozianu wrote: > If you can do nothing better than trolling this conversation is over. You classify responding to your questions as trolling?! Jeff Brooks
Jeff Brooks <jeff_brooks@nospam.com> wrote in news:Rq1Zd.663609$Xk.345902 @pd7tw3no: > Costin Cozianu wrote: > >> If you can do nothing better than trolling this conversation is over. > > You classify responding to your questions as trolling?! I do :-)
|
|
0 |
|
Rich
3/14/2005 12:58:42 AM
Dmitry A. Kazakov wrote: > On Fri, 11 Mar 2005 11:01:20 -0800, Costin Cozianu wrote: > > > > It was *your* thesis that with such great advancements in RAM technology > > and OO and whatever, the SQL DBMS becomes a redundant element in the > > picture of a whole software system cause we don't need persistency no > > more, it'll be done automatically. > > Correction, that was Robert Martin, but I fully agree with him. The notion > of persistency is a relict of the era when distributed systems were > considered as an unstructured bunch of hosts. In future systems nothing > will persist, but only exist. > The issue isn't so much that something (data?) will simply exist, but rather what kind of model is used to represent it. The RDBMS presents one model. What kind of model do you envision? Regards, Daniel Parker
Jeff Brooks wrote: > Costin Cozianu wrote: > >> If you can do nothing better than trolling this conversation is over. > > > You classify responding to your questions as trolling?! > > Jeff Brooks No I classify pretending to respond while in fact not responding trolling. I might be highly subjective on that, but then you're free to take it with a grain of salt. Costin
paul campbell wrote: > On Fri, 11 Mar 2005 11:01:20 -0800, Costin Cozianu > <c_cozianu@hotmail.com> wrote: > > >> Well, I left the Java glue part as an exercise for the reader because >> it is trivial and boring, so it makes no sense to waste my time >> writing it in order to keep you happy. > > > This glue code is neverthless necessary for a meaningful direct comparison > with a OO domain model API. > For example how do you handle an attempt to breach your DB enforced > contraints - > do you allow the user to attempt the illegal operation on the DB and > just bounce > a DB level error straight back, or do you prehaps have an application > layer which > duplicates the constraints and issue a meaningfull error ?. > > Paul C. Since I am not expecting the OO code to be dealing with reporting the error condition, I don't think it is relevant for SQL code to do that either. And dealing with error conditions (like key violations, referential integrity violation, etc) is rather trivial either and irrelevant to the topic of this discussion. If you think there's some insight to be had from showing how to deal with error codes and constraint names, etc, that may certainly be a separate topic to explore but I don't see any. Now what you asked me depends very much on the design of the GUI of an application and this is way beyond the scope of my challenge. GUIs for editing groups and users can be designed such as to prevent some errors altogether while reporting the condition for those that cannot be prevented. For example the user tries to create a new group with a pre-existing name. The best practice to deal with this is obviously to run with the transaction, get the error back from the DB, and then map it to a user-friendly error message.
On 13 Mar 2005 18:18:55 -0800, Daniel Parker wrote: > Dmitry A. Kazakov wrote: >> On Fri, 11 Mar 2005 11:01:20 -0800, Costin Cozianu wrote: >> >>> It was *your* thesis that with such great advancements in RAM technology >>> and OO and whatever, the SQL DBMS becomes a redundant element in the >>> picture of a whole software system cause we don't need persistency no >>> more, it'll be done automatically. >> >> Correction, that was Robert Martin, but I fully agree with him. The notion >> of persistency is a relict of the era when distributed systems were >> considered as an unstructured bunch of hosts. In future systems nothing >> will persist, but only exist. >> > The issue isn't so much that something (data?) will simply exist, but > rather what kind of model is used to represent it. The RDBMS presents > one model. What kind of model do you envision? That's another question. Once all we are agree (?) that there must be no data engraved on something external to the application, one can discuss how to represent things *in* the application. The only answer I know is ADTs. Whether ADTs should have relational operations, be thread/process safe, support state transition semantics etc, all that is up to the application. I don't exclude that relational operations might be useful for some applications. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
Costin Cozianu wrote: > Allegations have veen made recently (Application vs. Business Logic > thread) that only if we had enough peristent RAM so that we can get rid > of Oracle and its ilk, milk and honey will flow all across the OO land > now freed from Object Relational (Psychological) Impedance Mismatch. > > Claims have been handwaved across this newsgroups that core > functionality implemented by DBMS engines was not needed because it > would be trivially covered by the brave OO coders writing their ADTs on > a case by case basis. > > Since this is old news, I thought I refer those brave OO coders to > something I created specifically for such occasions: > > http://c2.com/cgi/wiki?ManyToManyChallenge > > I'm waiting to see how OO weenies out there put their code where their > mouth is. > > In particular I would stress the requirement that whatever class or > object (for object based, Java Script kind of guys) you create to manage > the many to many relationship , it should be usable from the calling > context without any fear of deadlock or spurious results in a > multi-threaded environment. Again, persistence is not an issue -- data > need not be persisted (imagine you had your nvram or whatever). > > > --Costin Hi, I'm sorry I don't have time to pursue your challenge but I must say I'm a fan of what works. The Relational Model and certain RDBMS work for managing data in a multiuser environment, OTOH OOP can work well for programming. So I believe it's not a case of one versus the other, it's a case of using a multi-paradigm approach to get the best of both worlds. Together not A vs B. For many years I saw people treat data as precious and code as dirt, but then when they did their calculations (especially when they got hammered by the competition mainly because they had much better software systems) they realized that code was not cheap either, it's precious after all. Rather than being treated as some sort of parasite of the data the code needs to be given the respect it deserves. Conversely the database needs respect too, products like Oracle are very mature anyone wanting to replace it with something else had better do their homework. I've seen many fail because they tried something else. Cheers, Alex Kay.
alex991On 14 Mar 2005 03:56:46 -0800, alex99@medcentral.com.au wrote: >I'm sorry I don't have time to pursue your challenge but I must say I'm >a fan of what works. I supose that it is due to the big amount of work needed to solve the challenge without a DBMS. >The Relational Model and certain RDBMS work for managing data in a >multiuser environment, And in a single user enviroment too. > OTOH OOP can work well for programming. But it does not apply to data management. > So I >believe it's not a case of one versus the other Of course. Both might be used together. >, it's a case of using a >multi-paradigm approach to get the best of both worlds. Together not A >vs B. But we are discussing about DBMS vs direct file processing. Regards
Dmitry A. Kazakov wrote: > On 13 Mar 2005 18:18:55 -0800, Daniel Parker wrote: > > > Dmitry A. Kazakov wrote: > > >> On Fri, 11 Mar 2005 11:01:20 -0800, Costin Cozianu wrote: > >> > >>> It was *your* thesis that with such great advancements in RAM technology > >>> and OO and whatever, the SQL DBMS becomes a redundant element in the > >>> picture of a whole software system cause we don't need persistency no > >>> more, it'll be done automatically. > >> > >> Correction, that was Robert Martin, but I fully agree with him. The notion > >> of persistency is a relict of the era when distributed systems were > >> considered as an unstructured bunch of hosts. In future systems nothing > >> will persist, but only exist. > >> > > The issue isn't so much that something (data?) will simply exist, but > > rather what kind of model is used to represent it. The RDBMS presents > > one model. What kind of model do you envision? > > That's another question. Once all we are agree (?) that there must be no > data engraved on something external to the application, I don't think we do :-) It's been widely observed that data is more stable than applications, and that isn't going to change, not to mention that 100 applications may be using the same data, so it seems reasonable to factor out data. Data in DBMSs survives programming paradigm shifts(e.g. from procedural to OO) and language changes (e.g. from C++ to Java or Visual Basic). Data is fundumental to enterprises in a way that applications are not, or rather, different applications will do but losing data is catostrophic. > one can discuss how > to represent things *in* the application. > > The only answer I know is ADTs. Whether ADTs should have relational > operations, be thread/process safe, support state transition semantics etc, > all that is up to the application. I don't exclude that relational > operations might be useful for some applications. > I can't see a future for computer software that isn't based on mathematical models, all areas of applied science go that way once they become mature. And I don't think the concept of an ADT per se has enough structure to support formal approaches to software development. Regards, Daniel Parker
On 14 Mar 2005 06:57:38 -0800, Daniel Parker wrote: > Dmitry A. Kazakov wrote: >> On 13 Mar 2005 18:18:55 -0800, Daniel Parker wrote: >> >>> Dmitry A. Kazakov wrote: >> >>>> On Fri, 11 Mar 2005 11:01:20 -0800, Costin Cozianu wrote: >>>> >>>>> It was *your* thesis that with such great advancements in RAM technology >>>>> and OO and whatever, the SQL DBMS becomes a redundant element in the >>>>> picture of a whole software system cause we don't need persistency no >>>>> more, it'll be done automatically. >>>> >>>> Correction, that was Robert Martin, but I fully agree with him. The notion >>>> of persistency is a relict of the era when distributed systems were >>>> considered as an unstructured bunch of hosts. In future systems nothing >>>> will persist, but only exist. >>>> >>> The issue isn't so much that something (data?) will simply exist, but >>> rather what kind of model is used to represent it. The RDBMS presents >>> one model. What kind of model do you envision? >> >> That's another question. Once all we are agree (?) that there must be no >> data engraved on something external to the application, > > I don't think we do :-) It's been widely observed that data is more > stable than applications, Some 100 postings above I stated that data without application is memory. Nobody disagreed that time. (:-)) Nevertheless, the observation you mention is wrong. Let you have an old 7" floppy, but no RT-11 OS under which this floppy was written? > and that isn't going to change, not to > mention that 100 applications may be using the same data, so it seems > reasonable to factor out data. These 100 applications + 1000 more, comprise another application where they all they exist together with the data. > Data in DBMSs survives programming > paradigm shifts(e.g. from procedural to OO) and language changes (e.g. > from C++ to Java or Visual Basic). What wonders me more is that Basic has managed it too. There must a lot of sense in numbering program statements! I think that could a viable alternative to ADT! (:-)) > Data is fundumental to enterprises > in a way that applications are not, or rather, different applications > will do but losing data is catostrophic. > >> one can discuss how >> to represent things *in* the application. >> >> The only answer I know is ADTs. Whether ADTs should have relational >> operations, be thread/process safe, support state transition semantics etc, >> all that is up to the application. I don't exclude that relational >> operations might be useful for some applications. > I can't see a future for computer software that isn't based on > mathematical models, all areas of applied science go that way once they > become mature. Fully agree. > And I don't think the concept of an ADT per se has > enough structure to support formal approaches to software development. Again agree. ADT is just a framework for expressing formal constructions. But isn't strange to set off one of such constructions against the whole framework? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
Alfredo Novoa wrote:
> On Sat, 12 Mar 2005 22:25:48 +0100, Bruno Desthuilliers
> <bdesth.quelquechose@free.quelquepart.fr> wrote:
>
>
>>>If the business logic is enforced by the DBMS you don't need to build
>>>a program with business logic. That's evident.
>>
>>And if the DBMS can't enforce the business logic, you need to build it
>>into the program. That's evident too...
>
> If something can not enforce the business logic then it is not a DBMS.
Ho, yes ?-) So no one of us never ever worked with a DBMS, cause such a
thing does not exists (by your definition).
May I remind you that a DBMS is a program that has it's own business
logic (it's business being, as the accronym implie, to manage data), and
that a not-so-small part of this logic (the one dealing with internal
data and indexes representation, IO access, request optimisation etc
etc...) cannot be enforced by a DBMS ?
Unless of course you define 'business logic' as 'any rule my favorite
RDBMS can enforce, and no other', which would make your assertion a
tautology - and would be a bit unfair too...
>>>Network DBMS's (and OODBMS's are network DBMS's) were an intermediate
>>>evolutionary step between file processing and RDBMS's. Now they are
>>>completely obsolete.
>>
>>That's probably why with Zope's ZODB I can write a whole CMS without
>>having to even bother about data storage.
>
> No, OODBMS's are not obsolete for that.
So they are not 'completely obsolete' ?
>>OODBMS have pros and cons. RDBMS have pros and cons.
>
> Of course, but if we compare OODBMS's to RDBMS's then OODBMS's don't
> have any technical pro.
What you mean 'technical' pro ?-)
I've worked (and still have to) with RDBMS based CMS. At least half the
code is related to connecting to the RDBMS, building SQL queries,
executing queries, checking queries results, fetching datas etc... And
at least half of the data handled by the RDBMS is not really suited to
the relational model (loosely structured data) and/or not used by any
application other than the CMS itself.
Using the ZODB (with or without Zope) saves me (and my customers) a
whole lot of time since I don't have to write boilerplate persistence
code. Performances are quite ok too, so I don't see any 'technical' pro
using a RDBMS here.
Note that it doesn't prevent me from using other data sources (RDBMS,
LDAP etc) when necessary or more suited. As I said, it all comes down to
using the right tool for the job at hand. When it happens that a RDBMS
is the right tool, I of course try to use it as intensively as possible.
It just happens that a RDBMS is not always the right tool.
Regards
--
bruno desthuilliers
ruby -e "print 'onurb@xiludom.gro'.split('@').collect{|p|
p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"
onurbOn Mon, 14 Mar 2005 18:12:47 +0100, bruno modulix <onurb@xiludom.gro> wrote: > Alfredo Novoa wrote: >> On Sat, 12 Mar 2005 22:25:48 +0100, Bruno Desthuilliers >> <bdesth.quelquechose@free.quelquepart.fr> wrote: >> >> >>>>If the business logic is enforced by the DBMS you don't need to build >>>>a program with business logic. That's evident. >>> >>>And if the DBMS can't enforce the business logic, you need to build it >>>into the program. That's evident too... >> >> If something can not enforce the business logic then it is not a DBMS. > > Ho, yes ?-) So no one of us never ever worked with a DBMS, cause such a > thing does not exists (by your definition). > I suppose it would be frightfully unsporting to point out the high line count of the source code for a DBMS, that may well have been written using OO priniples. Indeed, there's no reason to imagine someone writing an RDBMS today wouldn't use OOP to do it.
> I suppose it would be frightfully unsporting > to point out the high line > count of the source code for a DBMS, that may well have been written > using OO priniples. > Indeed, there's no reason to imagine someone writing an RDBMS today > wouldn't use OOP to do it. I don't see why either of those are relavant. It is almost like saying that everything is 1's and 0's underneath, therefore we should use binary for *everything*. Even if OOP was better for writing systems software, such as RDBMS code, that may not necessarily extrapolate to application developer. For one, the RDBMS builder does not really have relational itself as a tool, but the app developer does. -T-
(* They do model things differently but you can't write software in
sql. Saying SQL is better than OO is meaningless because sql is
insuffient to build software with. This is an apples to oranges
comparison. A better comparison is procedural, and OO paradigms.
Perhaps looking at which types of language supports the relational
model best might be a good idea. *)
I disagree. The problem is that one cannot really match them up
one-to-one. Procedural and relational tend to work together dividing up
concerns based on what each does best. Procedural by itself stinks, and
relational by itself is limited. It is the Ying and Yang interaction
that provides the beauty and consistency in my opinion.
OO is kind of a jack of all trades but master of none.
-T-
(* That's why I asked you if you had a more accessible and comprehensible treatment of the subject to see if there's anything that can change my mind. *) Hey Costin, you just got a "book stop" :-) (c2.com wiki inside humor) -T-
On Mon, 14 Mar 2005 17:37:42 GMT, Charles Krug <cdkrug@worldnet.att.net> wrote: >I suppose it would be frightfully unsporting to point out the high line >count of the source code for a DBMS, that may well have been written >using OO priniples. > >Indeed, there's no reason to imagine someone writing an RDBMS today >wouldn't use OOP to do it. Nobody is discussing that. In fact I am writing an RDBMS today using OOP. Regards.
Dmitry A. Kazakov wrote: > On 14 Mar 2005 06:57:38 -0800, Daniel Parker wrote: > > > Dmitry A. Kazakov wrote: >> > > And I don't think the concept of an ADT per se has > > enough structure to support formal approaches to software development. > > Again agree. ADT is just a framework for expressing formal constructions. > But isn't strange to set off one of such constructions against the whole > framework? > I'm not sure that a relation (row) can usefully be regarded as an instance of an ADT, it's just a set of typed values. But that aside, I would be happy to hear about other "constructions", as you put it; I would be more interested in this thread if that was what it was about. Regards, Daniel Parker
On 14 Mar 2005 11:11:23 -0800, Daniel Parker wrote: > Dmitry A. Kazakov wrote: >> On 14 Mar 2005 06:57:38 -0800, Daniel Parker wrote: >> >>> Dmitry A. Kazakov wrote: >>> >>> And I don't think the concept of an ADT per se has >>> enough structure to support formal approaches to software development. >> >> Again agree. ADT is just a framework for expressing formal constructions. >> But isn't strange to set off one of such constructions against the whole >> framework? >> > I'm not sure that a relation (row) can usefully be regarded as an > instance of an ADT, it's just a set of typed values. It could be very useful. Consider the following (real-life) example. Let we do machine learning. A natural representation of a training set is a table of rows. Each row is a training example. Cells are values of the features. It is quite relational, right? Now, imagine that some of the features are dependant. That is the values of some features are [partially] evaluated from the values of others. Training can be significantly (VERY) improved if you know the history of a query. Say, you have queried the feature x1 in the row. It could be not a singleton but a distribution of probabilities or possibilities, no matter. You select one point of the realization and go further. Now want to know what part of the value of the feature x2 depends on the choice you made. So you have to query not for x2, but for the conditional x2 | x1 = choice. This complex query mechanics is ideally represented by a set of ADTs, which hides away all that mess from the learning algorithm. > I would be happy to hear about other "constructions", as you put it; I > would be more interested in this thread if that was what it was about. There are uncounted mathematical constructions which cannot be modeled at the present level of programming. Even more constructions will never be until indiscrete, infinite, random systems appear (if ever). But, eh, which thread did you mean? (:-)) This one was about a contest in thread-safe implementing mutually multiple dependent objects. If you meant that, then the "constructions" I would use to solve the challenge are: 1. Handles (reference counted User and Group) 2. Sets (of pointers to represent relationships internally) 3. String maps (for by-name search) 4. Protected object (for access serialization), alternatively, service task 5. Task to write a concurrent test programs -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
Daniel Parker wrote:
> Dmitry A. Kazakov wrote:
> > On 14 Mar 2005 06:57:38 -0800, Daniel Parker wrote:
> >
> > > Dmitry A. Kazakov wrote:
> >>
> > > And I don't think the concept of an ADT per se has
> > > enough structure to support formal approaches to software
> development.
> >
> > Again agree. ADT is just a framework for expressing formal
> constructions.
> > But isn't strange to set off one of such constructions against the
> whole
> > framework?
> >
> I'm not sure that a relation (row) can usefully be regarded as an
> instance of an ADT, it's just a set of typed values. But that aside,
I
> would be happy to hear about other "constructions", as you put it; I
> would be more interested in this thread if that was what it was
about.
It is perfectly valid.
There is no conceptual difference between :
type Person
{
name() : string ;
age() :cardinal ;
}
and
Person = string X cardinal
name : Person -> string
age : Person -> cardinal
name( (n,a) ) = n
age( (n,a) ) = a
However in implementation terms, there is a big difference
between things such as SQL and ADTs. In SQL, each tuple element
is an irreducible *data value* (with exceptions for in-built types
such as dates etc) . For an ADT, the tuple element may be data, or
may be *an operation that computes a value* .
As one who has nominal FP background, I can see 'ADT as tuple' being
simple to implement. Query engines should also be efficient, because
std FP infrastructure (referential transparency, lazy evaluation etc)
is already optimised for this kind of nastiness .
Regards,
Steven Perryman
ggroups5On Mon, 14 Mar 2005 16:35:33 +0100, "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote: >> I don't think we do :-) It's been widely observed that data is more >> stable than applications, > >Some 100 postings above I stated that data without application is memory. >Nobody disagreed that time. (:-)) I completely disagree. Data is data and memory is only a plaecholder like any other like a paper sheet. >Nevertheless, the observation you mention is wrong. He is very right >Let you have an old 7" >floppy, but no RT-11 OS under which this floppy was written? Then you don't have data. >These 100 applications + 1000 more, comprise another application where they >all they exist together with the data. A set of applications is a system. >Again agree. ADT is just a framework for expressing formal constructions. >But isn't strange to set off one of such constructions against the whole >framework? What do you mean? Regards
On Mon, 14 Mar 2005 18:12:47 +0100, bruno modulix <onurb@xiludom.gro> wrote: >> If something can not enforce the business logic then it is not a DBMS. > >Ho, yes ?-) So no one of us never ever worked with a DBMS, cause such a >thing does not exists (by your definition). What a nonsense! Of course they exist: Oracle, DB2, SQL Server, etc. >May I remind you that a DBMS is a program that has it's own business >logic (it's business being, as the accronym implie, to manage data), and >that a not-so-small part of this logic (the one dealing with internal >data and indexes representation, IO access, request optimisation etc >etc...) cannot be enforced by a DBMS ? What a nonsense! You don't know what business logic is. >That is not business logic! >Unless of course you define 'business logic' as 'any rule my favorite >RDBMS can enforce, and no other', which would make your assertion a >tautology - and would be a bit unfair too... Of course my statement was tautology! Business logic are: database structure, database constraints and database derivation rules. And an RDBMS is a software system that can enforce all that. But it is not my definition, it is the definition you can find on any book or web about business rules. http://www.businessrulesgroup.org/ http://www.brcommunity.com/ http://www.computerworld.com/printthis/2003/0,4814,84500,00.html >> Of course, but if we compare OODBMS's to RDBMS's then OODBMS's don't >> have any technical pro. > >What you mean 'technical' pro ?-) An objective pro. >I've worked (and still have to) with RDBMS based CMS. At least half the >code is related to connecting to the RDBMS, building SQL queries, Your testimonial is irrelevant. It is very probable that you were not using the SQL DBMS correctly, and SQL DBMS's are a lot worse than RDBMS's. Regards
Alfredo Novoa <alfredo_novoa@hotmail.com> wrote: >On Mon, 14 Mar 2005 18:12:47 +0100, bruno modulix <onurb@xiludom.gro> >wrote: > >>> If something can not enforce the business logic then it is not a DBMS. >> >>Ho, yes ?-) So no one of us never ever worked with a DBMS, cause such a >>thing does not exists (by your definition). > >What a nonsense! > >Of course they exist: Oracle, DB2, SQL Server, etc. > >>May I remind you that a DBMS is a program that has it's own business >>logic (it's business being, as the accronym implie, to manage data), and >>that a not-so-small part of this logic (the one dealing with internal >>data and indexes representation, IO access, request optimisation etc >>etc...) cannot be enforced by a DBMS ? > >What a nonsense! > >You don't know what business logic is. > >>That is not business logic! >>Unless of course you define 'business logic' as 'any rule my favorite >>RDBMS can enforce, and no other', which would make your assertion a >>tautology - and would be a bit unfair too... > >Of course my statement was tautology! > >Business logic are: database structure, database constraints and >database derivation rules. > I'd say the above are "possible implementations of business logic", rather than "Business logic". Don't confuse the implementation with the concept being implemented.
On Tue, 15 Mar 2005 13:06:32 +0100, Remi Bastide <FirstName.LastName@irit.fr> wrote: >>Business logic are: database structure, database constraints and >>database derivation rules. >> > >I'd say the above are "possible implementations of business logic", >rather than "Business logic". >Don't confuse the implementation with the concept being implemented. Who is confusing the concept with the implementation is you. Constraints and derivation rules are logical concepts and not implementation. You can implement a database constraint in the app although it is a bad idea. What is implementation are indices and all that Bruno mentioned. Regards
On Tue, 15 Mar 2005 12:33:11 +0100, Alfredo Novoa wrote: > On Mon, 14 Mar 2005 16:35:33 +0100, "Dmitry A. Kazakov" > <mailbox@dmitry-kazakov.de> wrote: > >>Let you have an old 7" >>floppy, but no RT-11 OS under which this floppy was written? > > Then you don't have data. Very true. No matter whether each ferromagnetic particles run an RDBMS or not. Without the application there is no data. >>These 100 applications + 1000 more, comprise another application where they >>all they exist together with the data. > > A set of applications is a system. Yes. My favorite "system" to work with all sorts of data consists of two applications: "fdisk" and "format". (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
Alfredo Novoa wrote:
> On Mon, 14 Mar 2005 18:12:47 +0100, bruno modulix <onurb@xiludom.gro>
> wrote:
>
>>>If something can not enforce the business logic then it is not a DBMS.
>>
>>Ho, yes ?-) So no one of us never ever worked with a DBMS, cause such a
>>thing does not exists (by your definition).
>
> What a nonsense!
>
> Of course they exist: Oracle, DB2, SQL Server, etc.
>
>>May I remind you that a DBMS is a program that has it's own business
>>logic (it's business being, as the accronym implie, to manage data), and
>>that a not-so-small part of this logic (the one dealing with internal
>>data and indexes representation, IO access, request optimisation etc
>>etc...) cannot be enforced by a DBMS ?
>
>
> What a nonsense!
What ? Stating that a DBMS is a program ? Stating that it's business is
to manage data ? Or stating that a DBMS cannot relie on a DBMS to
enforce (at least part of) the rules that pertain to it's business ?
> You don't know what business logic is.
I don't know (yet) what *you* mean by business logic.
>
>That is not business logic!
Depends on how you define business logic... let's see :
>>Unless of course you define 'business logic' as 'any rule my favorite
>>RDBMS can enforce, and no other', which would make your assertion a
>>tautology - and would be a bit unfair too...
>
>
> Of course my statement was tautology!
of course...
> Business logic are: database structure, database constraints and
> database derivation rules.
Lol.
This (obviously biased) definition implies that there is no business
logic in an application that dont use a database, so an application that
dont use a database can only handle presentation logic.
As you like to say : "What a nonsense!".
> And an RDBMS is a software system that can enforce all that.
I didn't say that a RDBMS could *not, never, in any way* be used to
enforce some kinds of business rules, did I ?
> But it is not my definition, it is the definition you can find on any
> book or web about business rules.
>
> http://www.businessrulesgroup.org/
> http://www.brcommunity.com/
> http://www.computerworld.com/printthis/2003/0,4814,84500,00.html
Nothing I saw on theses pages supported your statement that business
logic was directly tied to DBMS. If I missed something, please provide
links to more accurate documentation.
From what I saw, it's all about defining the rules that the application
(however it's implemented) must enforce to solve the customer's problem.
From this POV, I think it's perfectly valid to state that the
'business' of a DBMS program is to manage user's data and enforce user's
specified rules (users in this context being the DBA and the application
programmer). One exemple of the business rules for a RDBMS program is
that a primary key is unique - I let you think about the others...
If it's the usage of the 'business' word in that context that bother
you, please feel free to propose another - from my POV, it's equal.
>
>>>Of course, but if we compare OODBMS's to RDBMS's then OODBMS's don't
>>>have any technical pro.
>>
>>What you mean 'technical' pro ?-)
>
>
> An objective pro.
<troll>
Then what do you mean by 'objective' ?-)
</troll>
Ok, I'm not here to troll, and I pretty well understand what you mean.
Now what I meant here is that there is no such thing as an 'absolute'
superiority in this domain. The 'best' tool *for a given problem* is the
one that best solves *that* problem.
It's obvious that writing my programs in C could allow me to have much
more efficiency at runtime than what I can get from a Python interpreter.
But the fact is that for what I'm doing actually (web applications), C
would be a worst choice in terms of productivity - and my customer's
priority is more about productivity (how much time will it take to
implement this particular feature) than absolute efficiency (given that
actual perfs are considered good enough by the customer itself).
>
>>I've worked (and still have to) with RDBMS based CMS. At least half the
>>code is related to connecting to the RDBMS, building SQL queries,
>
> Your testimonial is irrelevant.
Of course, since it doesn't go your way.
> It is very probable that you were not
> using the SQL DBMS correctly,
Of course, I must be a very bad and illiterate programmer, not educated
enough to even have a clue about how to use a DBMS. This is of course
the only possible explanation to the fact I observed.
When facts comes in contradiction with theory, you can dismiss facts or
revise the theory...
> and SQL DBMS's are a lot worse than
> RDBMS's.
Would you categorize SQL Server, Oracle and Postgres as 'SQL DBMS' or
'RDBMS' ? and in the first case could you be kind enough to tell us
about existing RDBMS ?
Alfredo, I know that you know much more than me about RDBMS, and I would
not pretend being a better (or more expiremented or whatever) programmer
than you are (which doesn't implies that I know nothing about RDBMS or
programming...). Too bad you're so biased as to not even accept that
there exists a whole world of applications outside RDBMS based apps, and
that RDBMS are *not* the alpha and omega of application programming -
just a pretty nice and useful *tool*.
Have nice day !-)
Regards
--
bruno desthuilliers
ruby -e "print 'onurb@xiludom.gro'.split('@').collect{|p|
p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"
On Tue, 15 Mar 2005 14:53:57 +0100, bruno modulix <onurb@xiludom.gro> wrote: >>>May I remind you that a DBMS is a program that has it's own business >>>logic (it's business being, as the accronym implie, to manage data), and >>>that a not-so-small part of this logic (the one dealing with internal >>>data and indexes representation, IO access, request optimisation etc >>>etc...) cannot be enforced by a DBMS ? > >What ? Stating that a DBMS is a program ? Stating that it's business is >to manage data ? Or stating that a DBMS cannot relie on a DBMS to >enforce (at least part of) the rules that pertain to it's business ? Stating that physical representation, IO access and optimization is business logic. >> Business logic are: database structure, database constraints and >> database derivation rules. > >Lol. > >This (obviously biased) definition implies that there is no business >logic in an application that dont use a database, so an application that >dont use a database can only handle presentation logic. There are not applications that don't use data. Any organized data set is a database independently of the representation. On the other hand business logic is a term related to business systems. Business logic are business system database constraints. >> And an RDBMS is a software system that can enforce all that. > >I didn't say that a RDBMS could *not, never, in any way* be used to >enforce some kinds of business rules, did I ? What I say is that a DBMS must be computationally complete for being a DBMS. It must have all the power of a Turing complete language (and this consists basically in the "while" instruction). >Nothing I saw on theses pages supported your statement that business >logic was directly tied to DBMS. I never said that. Business logic is directly tied to the database, not the DBMS. Many people in this group confuse both concepts all the time, and this mistake explains many what you wrote. > If I missed something, please provide >links to more accurate documentation. I have found an interesting link http://www-db.stanford.edu/~ullman/dscb/ch1.pdf > From what I saw, it's all about defining the rules that the application The system, not the application. >(however it's implemented) must enforce to solve the customer's problem. No, that is a fuzzy definition. Business rules define what are the consistent states of a database. All business rules can be viewed as constraints. For instance if we define the following derivation rule: "the current stock is the initial stock plus the inputs minus the outputs", we are constrainting the value of the current stock attribute. > From this POV, I think it's perfectly valid to state that the >'business' of a DBMS program is to manage user's data and enforce user's >specified rules (users in this context being the DBA and the application >programmer). But it does not make any sense. A DBMS is a tool and the business logic concept don't apply to this internal level. ><troll> >Then what do you mean by 'objective' ?-) ></troll> Measurable. >Ok, I'm not here to troll, and I pretty well understand what you mean. > >Now what I meant here is that there is no such thing as an 'absolute' >superiority in this domain. And you are wrong. It was proved a long time ago. RDBMS's are (theoretically) absolutely superior to NDBMS's, although that is obviously not true for fatally flawed implementations like the ones we have. I agree on that a good NDBMS could be better than a bad SQL DBMS in some circumstances. But these circumstances are a lot less frequent than many people could think. > The 'best' tool *for a given problem* is the >one that best solves *that* problem. The problem is that I am talking about theoretical computational models and you are talking about concrete tools. >> Your testimonial is irrelevant. > >Of course, since it doesn't go your way. Testimonials don't make science. >Of course, I must be a very bad and illiterate programmer, not educated >enough to even have a clue about how to use a DBMS. This is of course >the only possible explanation to the fact I observed. > >When facts comes in contradiction with theory, you can dismiss facts or >revise the theory... You have to revise the experimentation method first. Do you remember cold fusion? :) And yours is obviously flawed because you didn't use a truly RDBMS. >Would you categorize SQL Server, Oracle and Postgres as 'SQL DBMS' or >'RDBMS' ? SQL DBMS of course. > and in the first case could you be kind enough to tell us >about existing RDBMS ? They don't exist. >Too bad you're so biased as to not even accept that >there exists a whole world of applications outside RDBMS based apps, and >that RDBMS are *not* the alpha and omega of application programming - >just a pretty nice and useful *tool*. At the present day, RDBMS's are (theoretically) the alpha and omega of the computerized data management, but they were never tried seriously (at practice). There are many people trying to dismiss the concept basing in misconceptions (the most) and in very bad implementations of the Relational Model. >Have nice day !-) You too. Regards
Costin Cozianu <c_cozianu@hotmail.com> wrote in message news:<3996q3F5uitbpU1@individual.net>...
> Allegations have veen made recently (Application vs. Business Logic
Snip ...
>
> http://c2.com/cgi/wiki?ManyToManyChallenge
>
> need not be persisted (imagine you had your nvram or whatever).
>
>
> --Costin
Hi, Costin!
Thanks for the excellent brain-teaser! It's like sitting to a good
crossword puzzle.
Here's a first attempt, but it's Java, and I don't want to go into the
two most difficult aspects (deadlocking/linear-time) before asking
about your comment, "A java version with 50 lines also has support
from the VM."
Does this mean that a Java version is immediately disqualified?
(Apologies for the format: I'm sure it will be mangled by my browser.)
Thanks
..ed
www.EdmundKirwan.com - Home of The Fractal Class Composition.
import java.util.List;
import java.util.ArrayList;
class Node {
private String name = null;
private List connectedNodes = new ArrayList();
static private List nodes = null;
Node(String name) {
this.name = name;
}
static List get(String query) {
List list = new ArrayList();
for (int i = 0, n = nodes.size(); i < n; i++) {
Node node = (Node)nodes.get(i);
node.query(list, query);
}
return list;
}
static Node getNode(String name) {
for (int i = 0, n = nodes.size(); i < n; i++) {
Node node = (Node)nodes.get(i);
if (node.name.equals(name)) {
return node;
}
}
return null;
}
void query(List list, String query) {
if (name.indexOf(query) != -1) {
list.add(this);
}
}
void addAssociatedNode(Node node) {
connectedNodes.add(node);
}
synchronized void remove() {
nodes.remove(this);
for (int i = 0, n = connectedNodes.size(); i < n; i++) {
Node connectedNode = (Node)connectedNodes.get(i);
connectedNode.disassociateNode(this);
}
}
void associateNode(Node node) {
addAssociatedNode(node);
node.addAssociatedNode(this);
}
synchronized void disassociateNode(Node node) {
connectedNodes.remove(node);
}
void update(String name) {
this.name = name;
}
public String toString() {
StringBuffer buffer = new StringBuffer();
for (int i = 0, n = connectedNodes.size(); i < n; i++) {
Node node = (Node)connectedNodes.get(i);
buffer.append(node.name + " ");
}
String retValue = name;
if (buffer.length() > 0) {
retValue = name + " (associated with " + buffer + ")";
}
return retValue;
}
public static void main(String[] args) {
nodes = new ArrayList(); // Create DB
Node man1Node = new Node("Man1"); // creations
Node man2Node = new Node("Man2");
Node man3Node = new Node("Man3");
Node group1Node = new Node("Group1");
nodes.add(man1Node);
nodes.add(man2Node);
nodes.add(man3Node);
nodes.add(group1Node);
man1Node.associateNode(group1Node); // Relationship
man3Node.associateNode(group1Node);
System.out.println("nodes = " + nodes);// Navigate
group1Node.remove(); // Deletion
System.out.println("nodes = " + nodes);
man1Node.update("Monkey1"); // Update
System.out.println("nodes = " + nodes);
System.out.println("All nodes with y: " + get("y"));
}
}
iamfractaliamfractal@hotmail.com wrote: > Costin Cozianu <c_cozianu@hotmail.com> wrote in message news:<3996q3F5uitbpU1@individual.net>... > >>Allegations have veen made recently (Application vs. Business Logic > > > Snip ... > > >>http://c2.com/cgi/wiki?ManyToManyChallenge >> >>need not be persisted (imagine you had your nvram or whatever). >> >> >>--Costin > > > Hi, Costin! > > Thanks for the excellent brain-teaser! It's like sitting to a good > crossword puzzle. > > Here's a first attempt, but it's Java, and I don't want to go into the > two most difficult aspects (deadlocking/linear-time) before asking > about your comment, "A java version with 50 lines also has support > from the VM." > > Does this mean that a Java version is immediately disqualified? > Of course not. That particular comment was't made by me (wiki is a collective authorship scheme) and probably is not formulated very clearly. I guess it was meant to say that it's fair to count the SQL solutions as havign only few lines of code with the support of many more behind the scenes functionality provided by the RDBMS, because that's what RDBMSes are supposed to do. I guess I should remove the comment from the "disqualifications" section. Costin
Alfredo Novoa wrote:
> On Tue, 15 Mar 2005 14:53:57 +0100, bruno modulix <onurb@xiludom.gro>
> wrote:
>
>
>>>>May I remind you that a DBMS is a program that has it's own business
>>>>logic (it's business being, as the accronym implie, to manage data), and
>>>>that a not-so-small part of this logic (the one dealing with internal
>>>>data and indexes representation, IO access, request optimisation etc
>>>>etc...) cannot be enforced by a DBMS ?
>>
>>What ? Stating that a DBMS is a program ? Stating that it's business is
>>to manage data ? Or stating that a DBMS cannot relie on a DBMS to
>>enforce (at least part of) the rules that pertain to it's business ?
>
>
> Stating that physical representation, IO access and optimization is
> business logic.
I may not have choosed the best examples (or at least their should be
more explanations about why this has to do with the DBMS's business
logic). Please re-read with "enforcing the uniqueness of a primary key",
which is a rule, and has nothing to do with how the rule is enforced by
a given DBMS).
>
>>>Business logic are: database structure, database constraints and
>>>database derivation rules.
>>
>>Lol.
>>
>>This (obviously biased) definition implies that there is no business
>>logic in an application that dont use a database, so an application that
>>dont use a database can only handle presentation logic.
>
>
> There are not applications that don't use data. Any organized data set
> is a database independently of the representation.
At which threshold do you consider that data is enough of an "organized
data set" to become a database ? Is the in-memory representation of a
bitmap a database ?
> On the other hand business logic is a term related to business
> systems.
As I said, if it's the word 'business' that dont please you, change it
for any other you like - the fact is that it doesn't change the problem:
an application (any application) has to enforce rules pertaining to its
goal (what the app is supposed to do for it's users), an not to mere
presentation.
> Business logic are business system database constraints.
My my my... Please, stop playing on words. You can't be such a troll.
>
>>>And an RDBMS is a software system that can enforce all that.
>>
>>I didn't say that a RDBMS could *not, never, in any way* be used to
>>enforce some kinds of business rules, did I ?
>
>
> What I say is that a DBMS must be computationally complete for being a
> DBMS. It must have all the power of a Turing complete language (and
> this consists basically in the "while" instruction).
Ok. BTW, I've re-read what you where saying and I think I've somewhat
misunderstood it a bit first time. One may or not agree with your above
statement, but it's not as insane as what I had understood previously.
>>Nothing I saw on theses pages supported your statement that business
>>logic was directly tied to DBMS.
>
> I never said that. Business logic is directly tied to the database,
> not the DBMS.
I didn't saw any mentions of databases neither !-)
> Many people in this group confuse both concepts all the time, and this
> mistake explains many what you wrote.
>
>>If I missed something, please provide
>>links to more accurate documentation.
>
> I have found an interesting link
>
> http://www-db.stanford.edu/~ullman/dscb/ch1.pdf
I'll have a look.
>
>>From what I saw, it's all about defining the rules that the application
>
> The system, not the application.
>
>>(however it's implemented) must enforce to solve the customer's problem.
>
> No, that is a fuzzy definition. Business rules define what are the
> consistent states of a database.
This is not what I saw from your links, and I think *your* definition is
somewhat too limitative - may I say, err... too database-centric ?-)
But if you're talking about "consistent state of the data and possible
data changes from this change", we may agree.
> All business rules can be viewed as constraints. For instance if we
> define the following derivation rule: "the current stock is the
> initial stock plus the inputs minus the outputs", we are constrainting
> the value of the current stock attribute.
>
Right.
>>From this POV, I think it's perfectly valid to state that the
>>'business' of a DBMS program is to manage user's data and enforce user's
>>specified rules (users in this context being the DBA and the application
>>programmer).
>
>
> But it does not make any sense. A DBMS is a tool
Of course. But it's *also* an application.
> and the business
> logic concept don't apply to this internal level.
What is 'internal level' for one app (or system if you prefer) is
business logic for a part of the app (or for a subsystem if you prefer)
>
>><troll>
>>Then what do you mean by 'objective' ?-)
>></troll>
>
>
> Measurable.
This one didn't call no answer, but thanks anyway.
BTW, is the application programmer's productivity an 'objective
measurable technical pro' ?
>
>>Ok, I'm not here to troll, and I pretty well understand what you mean.
>>
>>Now what I meant here is that there is no such thing as an 'absolute'
>>superiority in this domain.
>
>
> And you are wrong. It was proved a long time ago. RDBMS's are
> (theoretically)
at least !-)
> absolutely superior to NDBMS's, although that is
> obviously not true for fatally flawed implementations like the ones we
> have.
>
> I agree on that a good NDBMS could be better than a bad SQL DBMS in
> some circumstances. But these circumstances are a lot less frequent
> than many people could think.
Frequency of the circonstance is in the daya-to--day experience of each
and every programmer. This may not be 'absolutely frequent', but this is
at least frequently true for me on a day to day basis.
>
>>The 'best' tool *for a given problem* is the
>>one that best solves *that* problem.
>
> The problem is that I am talking about theoretical computational
> models and you are talking about concrete tools.
Seems so.
>
>>>Your testimonial is irrelevant.
>>
>>Of course, since it doesn't go your way.
>
>
> Testimonials don't make science.
No, but science is not about discarding facts to keep the theory valid.
>
>>Of course, I must be a very bad and illiterate programmer, not educated
>>enough to even have a clue about how to use a DBMS. This is of course
>>the only possible explanation to the fact I observed.
>>
>>When facts comes in contradiction with theory, you can dismiss facts or
>>revise the theory...
>
> You have to revise the experimentation method first. Do you remember
> cold fusion? :)
>
> And yours is obviously flawed because you didn't use a truly RDBMS.
So no-one ever uses a 'truly RDBMS' ? Does at least such a beast exists?
>
>>Would you categorize SQL Server, Oracle and Postgres as 'SQL DBMS' or
>>'RDBMS' ?
>
>
> SQL DBMS of course.
>
>
>>and in the first case could you be kind enough to tell us
>>about existing RDBMS ?
>
>
> They don't exist.
Here we are.
>
>>Too bad you're so biased as to not even accept that
>>there exists a whole world of applications outside RDBMS based apps, and
>>that RDBMS are *not* the alpha and omega of application programming -
>>just a pretty nice and useful *tool*.
>
>
> At the present day, RDBMS's are (theoretically)
as you say !-)
> the alpha and omega of
> the computerized data management, but they were never tried seriously
> (at practice). There are many people trying to dismiss the concept
I'm not. Even the poor, flawed SQL DBMS we have are already nice and
useful tools - for at least some problems.
> basing in misconceptions (the most) and in very bad implementations of
> the Relational Model.
Please believe that it's not my case.
Thanks for this answer - it's always a pleasure to troll^M^M^M^Mdiscuss
with you.
Regards
--
bruno desthuilliers
ruby -e "print 'onurb@xiludom.gro'.split('@').collect{|p|
p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
Rich MacDonald wrote: > Jeff Brooks <jeff_brooks@nospam.com> wrote in news:Rq1Zd.663609$Xk.345902 > @pd7tw3no: > >>Costin Cozianu wrote: >> >>>If you can do nothing better than trolling this conversation is over. >> >>You classify responding to your questions as trolling?! > > I do :-) Hehe :-)
topmind wrote: > (* They do model things differently but you can't write software in > sql. Saying SQL is better than OO is meaningless because sql is > insuffient to build software with. This is an apples to oranges > comparison. A better comparison is procedural, and OO paradigms. > Perhaps looking at which types of language supports the relational > model best might be a good idea. *) > > I disagree. The problem is that one cannot really match them up > one-to-one. Procedural and relational tend to work together dividing up > concerns based on what each does best. Procedural by itself stinks, and > relational by itself is limited. It is the Ying and Yang interaction > that provides the beauty and consistency in my opinion. > > OO is kind of a jack of all trades but master of none. Personally I think everything in IT sucks but everything sucks in different ways! Jeff Brooks
Alfredo Novoa wrote: > On 14 Mar 2005 03:56:46 -0800, alex99@medcentral.com.au wrote: > > >I'm sorry I don't have time to pursue your challenge but I must say I'm > >a fan of what works. > > I supose that it is due to the big amount of work needed to solve the > challenge without a DBMS. No, it's actually because my current employer (Cisco Systems) seems to prefer me to work on their project rather than on any challenges presented on the web ;-) Otherwise, I must say in the past 20 years I have happily implemented many large scale multi-user systems *without* using any DBMS's. I have also implemented many using a DBMS, going back since Oracle version 3. In my humble experience the systems involving DBMS's where much more work overall! Mind you, not much was ever gained for that extra work! Ok SQL is handy for hacking but I can also say I've never seen one system that used only a DBMS. It was always DBMS+something and in particular SQL+"something else". That "something else" is what makes or breaks the situation, it might be a report writer, 4GL, Perl, awk, Java, C/C++, PL/SQL or whatever. In real business, ANSI SQL can never stand by itself (or at least I've never seen it do so). So I stand by my original position, it's not a case of DBMS versus OOP they can work well together and if one must go without one of those items then I'd much rather loose the db! There are many other ways to deal with information and all very powerfully:- HTML/gif/jpg, XML, dbm files, serialization, regular files, corba, a multitude of web services etc etc ... Querying is only one piece of the jigsaw puzzle. In the end, I only use DB's if my client demands the extra sex appeal that comes by having one and not because they do anything for me. Frankly I would prefer a large enough nonvolitile memory bank with sufficient network facilities with not disk and no database. > >The Relational Model and certain RDBMS work for managing data in a > >multiuser environment, Multiuser - no problem. Unix is very comfortable handling multiple users. Threaded languages like Java can handle multiples every nicely too. Queries ... what's the problems? Best Regards, Alex Kay
alex99@medcentral.com.au wrote: >>>The Relational Model and certain RDBMS work for managing data in a >>>multiuser environment, > > > Multiuser - no problem. Unix is very comfortable handling multiple > users. Threaded languages like Java can handle multiples every nicely > too. Then you would have no problem posting the solution to the challenge, I understand. It's funny how in this thread (as well as in many others), everybody talks and talks and talks, brags and brags and brags, but in the end no code is posted. I guess that's comp.object, after all. Costin
> In real business, ANSI SQL can never stand by itself Did someone claim it could? > So I stand by my original position, it's not a case of DBMS versus OOP > they can work well together Indeed > In the end, I only use DB's if my client demands the extra sex appeal > that comes by having one and not because they do anything for me. Lets have an simple example. Lets say you have a list of customers and you want to find every customer above a given age living in a specific city. How would you do without a RDBMS? Traverse all customers and evaluate the criteria, or creating two maps, one for the birth_of_date property and one for the city property? Or would you have another solution? In SQL, the solution would be: select * from customers where (today-date_of_birth)<? and city=? Fredrik Bertilsson http://butler.sourceforge.net
But RDBMS provide many things out-of-the-box that are either difficult or create shop-to-shop inconsistency to roll by hand: # Persistence # Query languages or query ability (see DatabaseVerbs) # Metadata repository # State management # Multi-user contention management and concurrency (locks, transactions, rollbacks, etc.) # Backup and replication of data # Access security # Data computation/processing (such as aggregation and cross-referencing) # Data rule enforcement or validation # Data export and import utilities # Multi-language and multi-application data sharing # Data change and access logging # Automated "result path" optimization (user focuses on what, not on how) RDBMS simply factor commonly-used collection-handling idioms into a single tool so that you don't have to reinvent them from scratch. It is a concept called "reuse". > In my humble experience the systems involving DBMS's where > much more work overall! Mind you, not > much was ever gained for that extra work! I find that hard to believe. Creating such features from scratch cannot be the better bet. Maybe you just need a better DBA or more RDBMS training. I cannot tell from here what is dragging you down. > I have happily implemented many large scale > multi-user systems *without* using any DBMS's. One can also use Assembler if they really want. It is technically possible, just not pleasent. -T-
Costin Cozianu wrote: > alex99@medcentral.com.au wrote: > >>>The Relational Model and certain RDBMS work for managing data in a > >>>multiuser environment, > > > > > > Multiuser - no problem. Unix is very comfortable handling multiple > > users. Threaded languages like Java can handle multiples every nicely > > too. > > Then you would have no problem posting the solution to the challenge, I > understand. I agreed that DBMSs and SQL provide useful technology (my original post paragraph 2). It would take more lines of code to implement your particular challenge in an OO language of my choice, yes I agree with that too. Yet I have a completely different conclusion. At the simple end of the spectrum SQL shines, but at the complex end OOP shines and SQL can't even compete. The challenge happens to be limited to functionality that falls squarely within the reach of SQL and so it makes SQL shine. The logic appears to be "if SQL is so good at such a trivial example, then it must also be very good at more substantional examples". This is the problem. Technology does not scale linearly. I am constantly integrating diverse information sources:- from databases, sockets, XML, LDAP, text files, spreadsheets, Corba, MQ, EJBs, dbmfile's, web pages, email ... At this level of information management clearly a database and SQL is out of scope and beyond their realm. Something more powerful is required. For me, that something more powerful has been Perl and Java/OOP. Certain OO languages are up to the task, SQL isn't. Costin WROTE: At: http://c2.com/cgi/wiki?ManyToManyChallenge > BEGIN QUOTE > The challenge was intended to demonstrate that SQL has useful > functionality that is not readily available, nor trivially > implementable in OO environments. Agreed, however, I can re-use my OO solution. (snip) > In particular this page debunks a pervasive misconception > (see quotes ObjectRelationalPsychologicalMismatch) that > RelationalModel is not as good at representing > "relationships" as object models. > Which claim should be judged ridiculous on the face > of it, but it is amusing how many "important names" > in the OO camp make it. END QUOTE Nothing has been debunked. Relational technology is good at modeling relationships but only in limited contexts, beyond that you need something more powerful (like a good OOL). > It's funny how in this thread (as well as in many others), everybody > talks and talks and talks, brags and brags and brags, but in the end no > code is posted. I guess that's comp.object, after all. > > Costin If you're not convinced yet, please let me know and I'll issue a real world counter challenge ;-)
frebe wrote: > > In real business, ANSI SQL can never stand by itself > Did someone claim it could? > > > So I stand by my original position, it's not a case of DBMS versus > OOP > > they can work well together > Indeed > > > In the end, I only use DB's if my client demands the extra sex appeal > > that comes by having one and not because they do anything for me. > Lets have an simple example. Lets say you have a list of customers and > you want to find every customer above a given age living in a specific > city. How would you do without a RDBMS? Traverse all customers and > evaluate the criteria, or creating two maps, one for the birth_of_date > property and one for the city property? Or would you have another > solution? The information might be in a CSV file, XML, dbmfile, CORBA, MQ, EJB, LDAP, database, web page, spreadsheet ... and therefore the solution will vary. In essence I would have layers:- Layer 1. Get info from diverse source(s), Layer 2. Apply filters, Layer 3. Format and make pretty enough or presentation. SQL might help with Layer 1 SQL might help with Layer 2 but only if the query is simple enough. If not you need procedural or OO language help after all. > In SQL, the solution would be: > select * from customers where (today-date_of_birth)<? and city=? Sure in a vacuum that is a nice and simple query but please let me spice it up with a touch of reality. Let's put this in a real world context. The DBA team will not allow you to make any ad-hoc queries. You have 25 million customers and they don't like programmers poking with production systems. They eventually agree to FTP to your machine a compressed CSV dump of the customer table, they do that at 3AM Sunday mornings. How do we do the query now? The manager sees some output but complains that he can't read it, it isn't pretty enough, he wants a web page. You create a very nice page, but it's too long, it hangs the browser, we need to paginate the result. There where 7 millions rows so the network guys are screaming. How do we do the paginated query? After a while they realize they want this query all the time with live data, so you get permission to run SQL on the database. Great but our driver only allows us to move forward, we also need to go page backwards. The new super-e-business-guru has decided to put all customer information in an EJB and the manager has agreed. The new web page version of the query is getting really funky now, he wants to ensure customers have a matching record in the Radius Authentication Server. .... and while you're at it check to ensure they exist in the all important billing system. Accounts interface with CORBA but internally they use Oracle (which is behind 3 firewalls). Hmmm a join across different kinds of systems. Now what? .... I hope can you see my point ;-) > Fredrik Bertilsson > http://butler.sourceforge.net Regards, Alex Kay
topmind wrote: > But RDBMS provide many things out-of-the-box that are either difficult > or create shop-to-shop inconsistency to roll by hand: > > # Persistence > # Query languages or query ability (see DatabaseVerbs) > # Metadata repository > # State management > # Multi-user contention management and concurrency (locks, > transactions, rollbacks, etc.) > # Backup and replication of data > # Access security > # Data computation/processing (such as aggregation and > cross-referencing) > # Data rule enforcement or validation > # Data export and import utilities > # Multi-language and multi-application data sharing > # Data change and access logging > # Automated "result path" optimization (user focuses on what, not on > how) > > RDBMS simply factor commonly-used collection-handling idioms into a > single tool so that you don't have to reinvent them from scratch. It is > a concept called "reuse". > > > In my humble experience the systems involving DBMS's where > > much more work overall! Mind you, not > > much was ever gained for that extra work! > > I find that hard to believe. Creating such features from scratch cannot > be the better bet. Maybe you just need a better DBA or more RDBMS > training. I cannot tell from here what is dragging you down. I didn't need, want, nor create all those features from scratch, of course that would be a big job. But the humble dbm file (available on unix since the 80s) can go a very long way. Perl has a *one* line function for using them. Beyond that all you need is locking and your ready to serve the web ;-) Millions of hits, thousands of users. What was the problem? Absolutely nothing. What would a database have gained? A headache, much more code, complexity and the ability to run ad-hoc queries but wait a minute the system is live the dba's wouldn't allow programmers to poke with it, no ad-hoc queries after all. > > I have happily implemented many large scale > > multi-user systems *without* using any DBMS's. Think MiddleWare. Corba, MQ, EJB, XML, web, ... All these puppies can handle information too, databases aren't the only show in town ;-) > One can also use Assembler if they really want. It is technically > possible, just not pleasent. Now that I have not done. The last assembler I did was 20 years ago, you're right it wasn't pleasent, 8086 not nice, Rockwell 6502 not nice, Motorola 68000 was ok. > -T- Cheers.
alex99@medcentral.com.au wrote: > Costin Cozianu wrote: > >>alex99@medcentral.com.au wrote: >> >>>>>The Relational Model and certain RDBMS work for managing data in a >>>>>multiuser environment, >>> >>> >>>Multiuser - no problem. Unix is very comfortable handling multiple >>>users. Threaded languages like Java can handle multiples every > > nicely > >>>too. >> >>Then you would have no problem posting the solution to the challenge, > > I > >>understand. > > > I agreed that DBMSs and SQL provide useful technology (my original post > paragraph 2). > > It would take more lines of code to implement your particular challenge > in an OO language of my choice, yes I agree with that too. > How many more lines of code ? > Yet I have a completely different conclusion. > Unfounded conclusions, you can have thousands. > At the simple end of the spectrum SQL shines, but at the complex end > OOP shines and SQL can't even compete. > Useless trivia. > The challenge happens to be limited to functionality that falls > squarely within the reach of SQL and so it makes SQL shine. > > The logic appears to be "if SQL is so good at such a trivial example, > then it must also be very good at more substantional examples". This is > the problem. Technology does not scale linearly. > It happens like this: if for OO code is so complex to manage almost the simplest of relationships ... > I am constantly integrating diverse information sources:- from > databases, sockets, XML, LDAP, text files, spreadsheets, Corba, MQ, > EJBs, dbmfile's, web pages, email ... > Irrelevant. > At this level of information management clearly a database and SQL is > out of scope and beyond their realm. Something more powerful is > required. Non-sense. If you want to call a Ferrari more powerful than a Freightliner, it will only betray your ignorance. You can't haul trailers with Ferrari, so anybody who claims one "better" than the other is just a dumb ignorant. You cannot manage (i.e. conveniently supplant the features provided by DBMS) data with OO constructs. And that's the bottom line. What you do in the other layers is totally irrelevant. > For me, that something more powerful has been Perl and > Java/OOP. > > Certain OO languages are up to the task, SQL isn't. > > No, you can't street race with a Freightliner. You can haul trailers. > Costin WROTE: At: http://c2.com/cgi/wiki?ManyToManyChallenge > > BEGIN QUOTE > >>The challenge was intended to demonstrate that SQL has useful >>functionality that is not readily available, nor trivially >>implementable in OO environments. > > > Agreed, however, I can re-use my OO solution. > The non-existent one that you handwave about it. > (snip) > > >>In particular this page debunks a pervasive misconception >>(see quotes ObjectRelationalPsychologicalMismatch) that >>RelationalModel is not as good at representing >>"relationships" as object models. > > >>Which claim should be judged ridiculous on the face >>of it, but it is amusing how many "important names" >>in the OO camp make it. > > > END QUOTE > > Nothing has been debunked. > Posted so long ago and nobody managed to produce codce, hmmm. Call it what you like, I call it debunking. > Relational technology is good at modeling relationships but only in > limited contexts, beyond that you need something more powerful (like a > good OOL). > Smacks of marketing brochure speak. Why would anyone give your handwaved claim any credence ?
alex99@medcentral.com.au wrote:
> In essence I would have layers:-
> Layer 1. Get info from diverse source(s),
> Layer 2. Apply filters,
> Layer 3. Format and make pretty enough or presentation.
If you filter your data after you retrieve it, you will have to
traverse every object and you will have a linear search. Doing this is
the same as dismissing 40 years of computer science.
> SQL might help with Layer 2 but only if the query is simple enough.
If
> not you need procedural or OO language help after all.
I have seen many examples of this case, then a procedural language has
to implement a filter because SQL can't do it. But in every case it was
possible to redesign the database schema to enable SQL to do its job.
If you do a linear procedural filtering, your perforance will be bad.
> The DBA team will not allow you to make any ad-hoc queries.
I did not claim this to be a ad-hoc query. And why would not the DBA
team allow that?
> You have 25 million customers and they don't like programmers poking
> with production systems. They eventually agree to FTP to your machine
a
> compressed CSV dump of the customer table, they do that at 3AM Sunday
> mornings.
You have a database which is only accessable by a export utility? A did
not say I should be poking with the database. I'm talking about a new
feature in your application. I assume that you have a development
database to work with.
> You create a very nice page, but it's too long, it hangs the browser,
> we need to paginate the result. There where 7 millions rows so the
> network guys are screaming.
> How do we do the paginated query?
If you look at Butler (http://butler.sourceforge.net), you can see how
a paging query (ScrollQuery), based on any other query, is done. It is
a little bit complicated, but very deterministic. Any good SQL
framework should have a function for creating paging queries.
> After a while they realize they want this query all the time with
live
> data, so you get permission to run SQL on the database. Great but our
> driver only allows us to move forward, we also need to go page
> backwards.
Switching between forward and backward paging is just about chaning
operator ("<" to ">") and sort order ("asc" to "desc").
> The new super-e-business-guru has decided to put all customer
> information in an EJB and the manager has agreed.
EJB is not a place to "put information". It is a layer on top of a
database. Why would be manager only allow database acces through EJB?
What would he do with all his Crystal reports?
> The new web page version of the query is getting really funky now, he
> wants to ensure customers have a matching record in the Radius
> Authentication Server.
A good RDBMS could integrate an external authentication server.
> ... and while you're at it check to ensure they exist in the all
> important billing system. Accounts interface with CORBA but
internally
> they use Oracle (which is behind 3 firewalls).
Maybe you could use the replication feature in Oracle?
> Hmmm a join across different kinds of systems. Now what?
Most RDBMS:es can join from tables in other catalogs and schemas, as
long as they are in the same RDBMS instance.
> I hope can you see my point ;-)
You are just showing a lot of stupid limitations that your colleagues
gives you. None of this limitations has anything to do with a RDBMS.
And the limitations you show are very rare. The only argument that I
ever heard about before, is about authentication. But that is also
caused by an obsolete and stupid idea about "connection pooling". To
create an existence argument for application server software, you need
to invent a fake problem with the RDBMS.
Fredrik Bertilsson
http://butler.sourceforge.net
> Think MiddleWare. Corba, MQ, EJB, XML, web, ... All these puppies can > handle information too, databases aren't the only show in town ;-) Can you exaplain how you could use Corba, MQ or EJB without a backend DBMS? Fredrik Bertilsson http://butler.sourceforge.net
frebe wrote: > > Think MiddleWare. Corba, MQ, EJB, XML, web, ... All these puppies can > > handle information too, databases aren't the only show in town ;-) > > Can you exaplain how you could use Corba, MQ or EJB without a backend > DBMS? Entity beans in EJB are tied to databases but CORBA and MQ can be tied to anything. As a developer I'm only suppose to be aware of the agreed upon interface. That is the fence that divides me and them. Behind the scene they may have a battery of computers probing every telephone exchange in the country via 9600 baud serial connections. Or they may be connected to thousands of routers, switches and network devices or it may indeed be a database after all or a bunch of XML files ... I've encountered all of the above but it shouldn't matter to me. I'm suppose to be shielded from all that detail. From my experience I can say that that indeed was the case. I don't even know what was behind some of the MQ sytems? Maybe it was mice peddling on a wheel emitting MQ strings ;-) Cheers. > Fredrik Bertilsson > http://butler.sourceforge.net
Costin Cozianu wrote: > alex99@medcentral.com.au wrote: > > Costin Cozianu wrote: > > > >>alex99@medcentral.com.au wrote: > >> (snip) > > The challenge happens to be limited to functionality that falls > > squarely within the reach of SQL and so it makes SQL shine. > > > > The logic appears to be "if SQL is so good at such a trivial example, > > then it must also be very good at more substantional examples". This is > > the problem. Technology does not scale linearly. > > > > It happens like this: if for OO code is so complex to manage almost the > simplest of relationships ... > That is the problem, this reasoning assumes linear scalability but this isn't the case. Remember I am addressing your conclusion and not your challenge. The challenge focuses on SQL yet somehow the conclusion is far more general than that. You conclude ''In particular this page debunks a pervasive misconception ... that RelationalModel is *not as good* at representing "relationships" as object models.'' These are general, they apply to information and software beyond the sphere of DBs and SQL. Now consider the internals of a more complex model, say the internals of a wordprocessor or spreadsheet. They have plenty of "many to many" relationships in there. Yet SQL cannot be used for so much as one of them. Don't say this is irrelevant (as you do below). Had you limited your conclusion only to the sphere of the challenge then you may have a point. Had you concluded: "SQL provides some useful functionality that is not easily mimicked by using OOL's and it requires fewer lines of code to implement some features" then I would agree with you. However since you went on to generalize about the Object Model then you need to deal with its strengths not just the particular weakness you have chosen to showcase. You wanted to use the challenge to "debunk the misconception that the ''Relational Model is not as good at representing "relationships" as Object Models"'' Yet when I speak of scenarios that the OM is good at you say they are irrelevant. Costin you cannot have it both ways. Either change your conclusion, limit it only to the challenge or face the facts that the "RM implementations are not as good at modeling complex relationships as the object model" (to use words similar in style to yours). > > I am constantly integrating diverse information sources:- from > > databases, sockets, XML, LDAP, text files, spreadsheets, Corba, MQ, > > EJBs, dbmfile's, web pages, email ... > > > > Irrelevant. No. I am within scope of your conclusion where you speak of modeling relationships. The above technology models relationships and you speak of the Object Model, which I use for the above where OOP is up to the task SQL isn't. > > At this level of information management clearly a database and SQL is > > out of scope and beyond their realm. Something more powerful is > > required. > > > Non-sense. If you want to call a Ferrari more powerful than a > Freightliner, it will only betray your ignorance. You can't haul > trailers with Ferrari, so anybody who claims one "better" than the other > is just a dumb ignorant. Excuse me I was expecting an intelligent discussion, am I mistaken? In your conclusion you used the phrase "not as good" I have used the word "better" when I needed a negation, fair usage of the English language I would have thought. I am only addressing your conclusion in your own language. (Or am I confusing multiple authorship on wiki's?) > You cannot manage (i.e. conveniently supplant the features provided by > DBMS) data with OO constructs. And that's the bottom line. What you do > in the other layers is totally irrelevant. > > > For me, that something more powerful has been Perl and > > Java/OOP. > > > > Certain OO languages are up to the task, SQL isn't. > > > > > > No, you can't street race with a Freightliner. You can haul trailers. > > > > Costin WROTE: At: http://c2.com/cgi/wiki?ManyToManyChallenge > > > BEGIN QUOTE > > > >>The challenge was intended to demonstrate that SQL has useful > >>functionality that is not readily available, nor trivially > >>implementable in OO environments. > > > > > > Agreed, however, I can re-use my OO solution. > > > > The non-existent one that you handwave about it. > > > (snip) > > > > > >>In particular this page debunks a pervasive misconception > >>(see quotes ObjectRelationalPsychologicalMismatch) that > >>RelationalModel is not as good at representing > >>"relationships" as object models. > > > > > >>Which claim should be judged ridiculous on the face > >>of it, but it is amusing how many "important names" > >>in the OO camp make it. > > > > > > END QUOTE > > > > Nothing has been debunked. > > > > Posted so long ago and nobody managed to produce codce, hmmm. Call it > what you like, I call it debunking. You win one seat, which I have always acknowledged, then you claim victory in the entire election. Nice try. > > Relational technology is good at modeling relationships but only in > > limited contexts, beyond that you need something more powerful (like a > > good OOL). > > > > Smacks of marketing brochure speak. Why would anyone give your handwaved > claim any credence ? The credence to my claim is based on real world systems and they address relationships and modelling as generally as you do in your conclusion. (Not because I can mimick certain SQL features in less lines of OOL code as per your challenge). Had I contrived a simplistic example that showcases only my technology of choice and had I dismissed all else as irrelevant then yes it would smack of brochure speak. Thanks for the discussion, Alex Kay
<alex99@medcentral.com.au> wrote in message
news:1111311138.810693.56670@o13g2000cwo.googlegroups.com...
>
> These are general, they apply to information and software
> beyond the sphere of DBs and SQL.
>
> Now consider the internals of a more complex model, say the
> internals of a wordprocessor or spreadsheet.
>
> They have plenty of "many to many" relationships in there. Yet SQL
> cannot be used for so much as one of them.
> Don't say this is irrelevant (as you do below).
But it is, isn't it? You seem to be talking about physical storage and the
physical representation of data. The logical view of data in a spreadsheet
is as worksheets of labeled rows and columns. This view is extremely useful
for some puposes, say if you wanted to prepare a document describing data,
but less useful for others, say for supporting a data repository accessible
to multiple users. That's a feature of the fact that spreadsheets don't
impose much structure on the data, basically you have an ad hoc arrangement
of cells, although conventions for arranging the cells can be adopted to
support a tool for querying the data with SQL. But there's the issue of
data integrity. Think about trading floors where certain kinds of trades
live in traders' spreadsheets. Do you think regulatory agencies are
misguided in telling them that they have to enter those trades in proper
systems or stop trading?
> Had you concluded: "SQL provides some useful functionality
> that is not easily mimicked by using OOL's and it requires
> fewer lines of code to implement some features" then I
> would agree with you.
>
> However since you went on to generalize about the Object Model
> then you need to deal with its strengths not just the
> particular weakness you have chosen to showcase.
But there is no such thing as an "Object Model" of data. I don't know what
that means and I don't think you do either. Uncle Bob thinks he knows
("Objects that refer to each other using native language constructs. I
think this is a very nice logical model for lots and lots of data
processing") but he doesn't seem to know what "model" means.
To talk about a model in the sense of a relational model of data, you have
to be able to talk about the underlying mathematical model. If you can't do
that, you're not talking about a model.
Regards,
Daniel Parker
|
|
0 |
|
Daniel
3/20/2005 10:58:18 AM
frebe wrote:
> alex99@medcentral.com.au wrote:
> > In essence I would have layers:-
> > Layer 1. Get info from diverse source(s),
> > Layer 2. Apply filters,
> > Layer 3. Format and make pretty enough or presentation.
>
> If you filter your data after you retrieve it, you will have to
> traverse every object and you will have a linear search. Doing this
is
> the same as dismissing 40 years of computer science.
>
I'm sorry about the length of my replies but it's a huge topic.
Allow me to paste back some important bits that got snipped:-
I said:
"In the end, I only use DB's if my client demands the extra sex appeal
that comes by having one and not because they do anything for me."
You asked:
"How would you do without a RDBMS?"
* A fair question, which I aim to answer. However since there are many
non-database technologies I can't get into great technical detail.
So instead I chose to walk through some real world scenarios in order
to at least show how you can be without a database ...
I also said:
"The information might be in a CSV file, XML, dbmfile, CORBA, MQ, EJB,
LDAP, database, web page, spreadsheet ... and therefore the solution
will vary."
The filtering approach is not universal, it depends on the technology,
it would not be required with Corba or MQ but it is one approach I find
myself doing often.
For example if the supplier of my information only gives me an XML or
CSV file what am I do to? A linear scan of course.
> > SQL might help with Layer 2 but only if the query is simple enough.
> If
> > not you need procedural or OO language help after all.
>
> I have seen many examples of this case, then a procedural language
has
> to implement a filter because SQL can't do it. But in every case it
was
> possible to redesign the database schema to enable SQL to do its job.
I've worked in organizations who have millions of customers and
hundreds of thousands of employees, with huge databases - no redesign
was going to happen.
At any rate there are some difficult queries that are best done with
procedural help.
Or they can be computed much more quickly if done externally to the
database.
> If you do a linear procedural filtering, your perforance will be
bad.
Maybe then again maybe not.
I have many examples when performance was actually much better.
We were supplied a report that took 21 hours to run, it used the
database vendor's report writer and SQL to make all the appropriate
joins and queries. 21 hours!
We dumped all the required tables to CSV, that only took minutes. Then
we performing the join ourselves using AWK and computed the same result
in 19 minutes! Then for fun we did the same job in C, it took seconds.
Our performance was very good.
The thing is database optimizers, indexes and joins can easily be
beaten if you think about things.
> > The DBA team will not allow you to make any ad-hoc queries.
>
> I did not claim this to be a ad-hoc query. And why would not the DBA
> team allow that?
Every DBA I ever met "owns the database" the rest of us can only dream
of touching it.
Funny thing is when I was a DBA I did the same thing (blush).
> > You have 25 million customers and they don't like programmers
poking
> > with production systems. They eventually agree to FTP to your
machine
> a
> > compressed CSV dump of the customer table, they do that at 3AM
Sunday
> > mornings.
> You have a database which is only accessable by a export utility? A
did
> not say I should be poking with the database. I'm talking about a new
> feature in your application.
I didn't realize you're talking about a new feature in an application.
> You have a database which is only accessable by a export utility? A
did
> not say I should be poking with the database. I'm talking about a new
> feature in your application. I assume that you have a development
> database to work with.
Actually I may have no database at all, maybe only a Corba object or an
MQ....
> > You create a very nice page, but it's too long, it hangs the
browser,
> > we need to paginate the result. There where 7 millions rows so the
> > network guys are screaming.
> > How do we do the paginated query?
>
> If you look at Butler (http://butler.sourceforge.net), you can see
how
> a paging query (ScrollQuery), based on any other query, is done. It
is
> a little bit complicated, but very deterministic. Any good SQL
> framework should have a function for creating paging queries.
Yes I had a brief look at your work, I liked what I saw.
> > After a while they realize they want this query all the time with
> live
> > data, so you get permission to run SQL on the database. Great but
our
> > driver only allows us to move forward, we also need to go page
> > backwards.
>
> Switching between forward and backward paging is just about chaning
> operator ("<" to ">") and sort order ("asc" to "desc").
>
> > The new super-e-business-guru has decided to put all customer
> > information in an EJB and the manager has agreed.
>
> EJB is not a place to "put information". It is a layer on top of a
> database. Why would be manager only allow database acces through EJB?
To encapsulate the legecy system and distribute the information in a
database neutral fashion. There are many advantages, isolation of
schema
changes springs to mind as well as security, division of labor,
autonomy and performance. Middleware is very powerful if used wisely.
> What would he do with all his Crystal reports?
No, the manager is frightened by CR and we wants a web page so he can
show it off to his friends ;-)
> > The new web page version of the query is getting really funky now,
he
> > wants to ensure customers have a matching record in the Radius
> > Authentication Server.
>
> A good RDBMS could integrate an external authentication server.
Maybe but what if they don't allow it. I can't imagine the security
team allowing integration with ... well anyone else ;-|
> > ... and while you're at it check to ensure they exist in the all
> > important billing system. Accounts interface with CORBA but
> internally
> > they use Oracle (which is behind 3 firewalls).
>
> Maybe you could use the replication feature in Oracle?
>
Don't think so. The have explicitly hidden behind firewalls - no
access. You want access to our information, here is a limited view
via a CORBA object take it or leave it.
> > Hmmm a join across different kinds of systems. Now what?
>
> Most RDBMS:es can join from tables in other catalogs and schemas, as
> long as they are in the same RDBMS instance.
But I'm talking about information in different _kinds_ of systems.
> > I hope can you see my point ;-)
>
> You are just showing a lot of stupid limitations that your colleagues
> gives you. None of this limitations has anything to do with a RDBMS.
True they may appear stupid, but they are real world examples and
actually they are not limitations.
In large organizations departments do not allow their databases to be
hacked by everyone.
For ad-hoc work, if you're lucky, they might give you a CSV dump.
If it's an on-going need you will get access via their preferred
middleware (Corba, MQ, EJB...). One way or the other you will not
get direct access to their database. Nor should you want it!
This is encapsulation at the system level.
Actually these are not limitations but powerful enabling technologies.
> And the limitations you show are very rare. The only argument that I
> ever heard about before, is about authentication. But that is also
> caused by an obsolete and stupid idea about "connection pooling". To
> create an existence argument for application server software, you
need
> to invent a fake problem with the RDBMS.
Fredrik I'm not inventing fake problems, though I must admit they
probably sound that way, I'm just trying to walk through a non-database
world in response to your question "How would you do without a RDBMS?"
I know it can seem bizzare that there is no database (or there is but
it's hidden behind something else) but that is just how it is.
We needed to integrate across 60 large systems, can you imagine the
complete and utter chaos if everyone was allowed to access everyone' s
database directly?
How many schemas you would have to understand? How many schema changes
you'd want to avoid? How many fights about getting indexes built? No
thanks I'd rather have the encapsulated approach.
> Fredrik Bertilsson
> http://butler.sourceforge.net
Once again sorry about the long post.
Hopefully I've answered how and why there is no database and a little
bit of what I might do without one.
Cheers and thanks for the discussion,
Alex Kay.
alex99@medcentral.com.au wrote: > Entity beans in EJB are tied to databases but CORBA and MQ can be tied > to anything. > > As a developer I'm only suppose to be aware of the agreed upon > interface. That is the fence that divides me and them. It is exactly the same thing this SQL and ODBC/JDBC/ADO. It is an interface. The implementation can be anything from a simple flat file framework to a big monster such as Oracle. Corba has nothing at all to do this data management. It is only a mechanism for distributing method calls. Can you explain how CORBA would replace a RDBMS without having to implement all data management features by yourselft? MQ may be regarded as data management, but only in a very limited way. The only supported data structure is the queue and possibly the array. How would you solve the customer problem I asked you about before, using MQ? > Behind the scene they may have a battery of computers probing every > telephone exchange in the country via 9600 baud serial connections. Or > they may be connected to thousands of routers, switches and network > devices or it may indeed be a database after all or a bunch of XML > files ... Is this an argument for not using JDBC/ODBC/ADO? > I've encountered all of the above but it shouldn't matter to me. I'm > suppose to be shielded from all that detail. From my experience I can > say that that indeed was the case. I don't even know what was behind > some of the MQ sytems? Maybe it was mice peddling on a wheel emitting > MQ strings ;-) All this could be said about SQL too. Fredrik Bertilsson http://butler.sourceforge.net
On Sun, 20 Mar 2005 05:58:18 -0500, Daniel Parker wrote:
> <alex99@medcentral.com.au> wrote in message
> news:1111311138.810693.56670@o13g2000cwo.googlegroups.com...
>> Had you concluded: "SQL provides some useful functionality
>> that is not easily mimicked by using OOL's and it requires
>> fewer lines of code to implement some features" then I
>> would agree with you.
>>
>> However since you went on to generalize about the Object Model
>> then you need to deal with its strengths not just the
>> particular weakness you have chosen to showcase.
>
> But there is no such thing as an "Object Model" of data. I don't know what
> that means and I don't think you do either. Uncle Bob thinks he knows
> ("Objects that refer to each other using native language constructs. I
> think this is a very nice logical model for lots and lots of data
> processing") but he doesn't seem to know what "model" means.
>
> To talk about a model in the sense of a relational model of data, you have
> to be able to talk about the underlying mathematical model. If you can't do
> that, you're not talking about a model.
I think that is the point. What we are going to model? Do we mathematical
constructs, or something else? Let relational model do a mathematical
construct X. That may be very interesting, but useless if X does not model
another Y from the application domain. You may have perfect integer
numbers, but what you want is alas files. The result is that nasty UNIX
interface read / write / dup etc which treats files as numbers.
The general problem with mathematical models is that many of them are
infinite or contiguous. As such they are much more powerful than anything
one can build using computers. This makes them very difficult to formally
compare. Take integer numbers and you will be able to express any program
as a number. Does this help much? This is why I think that your argument is
logical but weak. To have an ability to compare we need much finer,
discrete models taking into account various constraints. There are usable
models for numeric methods, but there is nothing for anything larger than
that.
As for the "Object Model", you are right, because the ADT theory
corresponds to / is based on a *set* of mathematical models. It is a meta
model. A set is not equal to any of its elements. They are incomparable.
And, yes, the relational model belongs to that set. This is why people are
writing DBMS in OO languages, not the reverse. This is why there is no
problem to accomplish the challenge in an OO language.
Could the ADT theory be backed mathematically? I think it would be silly to
argue against it. Is there such a theory? No, we are in the position of
ancient Egyptians building their pyramids knowing nothing about
differential equations...
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
> For example if the supplier of my information only gives me an XML or > CSV file what am I do to? A linear scan of course. That's why you should use a SQL-compliant database for all your applications. Using a single standard has many advantages. > I've worked in organizations who have millions of customers and > hundreds of thousands of employees, with huge databases - no redesign > was going to happen. In every kind of software development a good design is necessary. If you don't do right from the beginning, it might be hard to correct the errors later. > We dumped all the required tables to CSV, that only took minutes. Then > we performing the join ourselves using AWK and computed the same result > in 19 minutes! Then for fun we did the same job in C, it took seconds. > Our performance was very good. Can you show me the CVS-files and AWK-files (send to me throug Butler)? I have to see this by myself before I believe it. > The thing is database optimizers, indexes and joins can easily be > beaten if you think about things. You have to prove this statement! > Every DBA I ever met "owns the database" The DBA should always have the final word about how a schema change should be done. But the request for a database change normally come from the development team. Otherwise the schema would never change. > the rest of us can only dream of touching it. That is because you don't know what a database is. If your team had some developers that knew something about databases, he would let you touch it. >>Why would be manager only allow database acces through EJB? >To encapsulate the legecy system Why does it need to be encapsulated? > distribute the information in a database neutral fashion. SQL databases are already distributed in a database vendor neutral fashion. There are a standard named ANSI SQL. All major database vendors supports a very large subset of this standard. > isolation of schema changes Can you give some example? > security All major current databases have a very good security system. > division of labor, Explaination please. > autonomy and performance. Middleware is very powerful if used wisely. A DBMS is very powerful is used wisely. >the manager is frightened by CR and we wants a web page so he can > show it off to his friends ;-) All major report tools (including Crystal) has a web front. > Maybe but what if they don't allow it. I can't imagine the security > team allowing integration with ... well anyone else ;-| But your security team will allow your application integrating with a Radius Authentication Server? > Don't think so. The have explicitly hidden behind firewalls - no > access. You want access to our information, here is a limited view > via a CORBA object take it or leave it. Your firewalls does not know that whether CORBA or something else is used. > In large organizations departments do not allow their databases to be > hacked by everyone. I never said anything about hacking the database. Usually a DBMS has a very competent security system. It may also be content-aware (different users have different access to different records). What you are suggesting is to have one single database user and disable the entire security system. I think that is a very bad idea. > We needed to integrate across 60 large systems, can you imagine the > complete and utter chaos if everyone was allowed to access everyone' s > database directly? My idea about good software engineering is that you have different databases (catalogs or schemas) for different applications. The inter-application communications is limited as far as possible to asynonchrous message exchange, data replication or read-only operations. > I'd rather have the encapsulated approach. I agree that applications should be encapsulated from each other. But you are argueing for encalulation within a single application. Fredrik Bertilsson http://butler.sourceforge.net
Daniel Parker wrote:
> <alex99@medcentral.com.au> wrote in message
> news:1111311138.810693.56670@o13g2000cwo.googlegroups.com...
> >
> > These are general, they apply to information and software
> > beyond the sphere of DBs and SQL.
> >
> > Now consider the internals of a more complex model, say the
> > internals of a wordprocessor or spreadsheet.
> >
> > They have plenty of "many to many" relationships in there. Yet SQL
> > cannot be used for so much as one of them.
>
> > Don't say this is irrelevant (as you do below).
>
> But it is, isn't it?
The wiki page says things like:
BEGIN
''"This is in contrast to claims of OO developers (DbasGoneBad,
PrevalenceLayer, etc) that if we could only get *SQL databases out of
the picture* then we'd have all milk and honey."
In particular this page debunks a pervasive misconception ... that
RelationalModel is *not as good* at representing "relationships" as
object models.''
END
The challenge is specifically based on SQL but the conclusions are at
the general technology level, "the picture" is general programming is
it not?
If it's so general then why can't I increase the sample size of test
cases in the discussion?
The notion of "many to many" isn't the sole properity of RDBMS and SQL
is it?
Must we only base the general conclusions on one special challenge?
I think not.
We either limit the conclusions to the scope of the challenge or
broaden the sample space.
> You seem to be talking about physical storage and the
> physical representation of data.
I was talking about the logic used to derive the above conclusion from
the issued challenge.
"If we can't mimick SQL's strengths then that proves the above
conclusion."
Fantastic but please just wait a minute, let's slow that right down and
have a better look.
> The logical view of data in a spreadsheet
> is as worksheets of labeled rows and columns. This view is extremely
useful
> for some puposes, say if you wanted to prepare a document describing
data,
> but less useful for others, say for supporting a data repository
accessible
> to multiple users. That's a feature of the fact that spreadsheets
don't
> impose much structure on the data, basically you have an ad hoc
arrangement
> of cells, although conventions for arranging the cells can be adopted
to
> support a tool for querying the data with SQL. But there's the issue
of
> data integrity. Think about trading floors where certain kinds of
trades
> live in traders' spreadsheets. Do you think regulatory agencies are
> misguided in telling them that they have to enter those trades in
proper
> systems or stop trading?
>
> > Had you concluded: "SQL provides some useful functionality
> > that is not easily mimicked by using OOL's and it requires
> > fewer lines of code to implement some features" then I
> > would agree with you.
> >
> > However since you went on to generalize about the Object Model
> > then you need to deal with its strengths not just the
> > particular weakness you have chosen to showcase.
>
> But there is no such thing as an "Object Model" of data.
True it isn't only about data but people talk about it, there are
papers and books about it, they are talking about _something_. They
call it the Object Model, there is also the Object Paradigm, Object
Oriented Programming, OO languages, etc etc. Don't any of these things
mean anything or exist?
> I don't know what that means and I don't think you do either.
True there is a lot of ambiguity but not due to a lack of definitions,
consensus is what we lack.
In the context of the wiki page I believe we are simply talking about
OO and relational technology in general not in terms of formal models.
> Uncle Bob thinks he knows
> ("Objects that refer to each other using native language constructs.
I
> think this is a very nice logical model for lots and lots of data
> processing") but he doesn't seem to know what "model" means.
I'm guessing he does know ;-)
> To talk about a model in the sense of a relational model of data, you
have
> to be able to talk about the underlying mathematical model. If you
can't do
> that, you're not talking about a model.
Not all models are mathematically based. Models of behavior of people
or of organizations don't necessarily have any underlying mathematical
model.
> Regards,
> Daniel Parker
Cheers,
Alex K
frebe wrote:
> > For example if the supplier of my information only gives me an XML
or
> > CSV file what am I do to? A linear scan of course.
> That's why you should use a SQL-compliant database for all your
> applications. Using a single standard has many advantages.
> > I've worked in organizations who have millions of customers and
> > hundreds of thousands of employees, with huge databases - no
redesign
> > was going to happen.
> In every kind of software development a good design is necessary. If
> you don't do right from the beginning, it might be hard to correct
the
> errors later.
Agreed.
>
> > We dumped all the required tables to CSV, that only took minutes.
> Then
> > we performing the join ourselves using AWK and computed the same
> result
> > in 19 minutes! Then for fun we did the same job in C, it took
> seconds.
> > Our performance was very good.
> Can you show me the CVS-files and AWK-files (send to me throug
Butler)?
> I have to see this by myself before I believe it.
That example was about 10 years and about 5 jobs ago. I don't have
access to it now. I can only assure you I am totally sincere and that
it is a true example.
The report was a monthly consolidation or summary, a cross tabulation
of
one field against another. X x Y. AWK has a pretty good associative
array
(hash map).
> > The thing is database optimizers, indexes and joins can easily be
> > beaten if you think about things.
> You have to prove this statement!
Why, am I on trial ;-)
We did it routinely.
On a production system with plenty of load apply some rather involved
queries especially requiring joins and maybe inner selects and time
them.
Then dump the same tables into CSV files and use something like AWK
or Perl to achieve the same joins. Maybe you'll be amazed.
Things like where X in ('a', 'b') versus X='a' or X='b' can make a big
difference in queries on some databases.
You can't always beat the database, especially a small one or on
systems
with very light loads but I just about always find some query I can do
much faster.
> > Every DBA I ever met "owns the database"
> The DBA should always have the final word about how a schema change
> should be done. But the request for a database change normally come
> from the development team. Otherwise the schema would never change.
>
> > the rest of us can only dream of touching it.
> That is because you don't know what a database is. If your team had
> some developers that knew something about databases, he would let you
> touch it.
Now now Fredrick, how can you make that statement about me you don't
even know who I am. You don't know what knowledge I have about
databases.
Nor do you know the dba's and the corporate policy (which is to ban
programmers from touching production systems without exception).
> >>Why would be manager only allow database acces through EJB?
> >To encapsulate the legecy system
> Why does it need to be encapsulated?
To avoid giving direct access to those outside their boundary.
Obviously the provider is affected but at least the other guys aren't
> > distribute the information in a database neutral fashion.
> SQL databases are already distributed in a database vendor neutral
> fashion. There are a standard named ANSI SQL. All major database
> vendors supports a very large subset of this standard.
Really, that's news to me. Everytime I use SQL I get bitten by vendor
specifics.
> > isolation of schema changes
> Can you give some example?
If the database is hidden behind let's say a Corba object or MQ then
those behind the fence can change their schema at will.
Of course their applications are affected by schema changes in the
traditional way.
However since we only communicate via a narrower interface we are not
affected.
Only when the interface changes are we affected.
> > security
> All major current databases have a very good security system.
Maybe, but people still hide them behind firewalls and middleware.
>
> > division of labor,
> Explaination please.
Once an interface is (pretty much) agreed upon work can be carried out
on both sides of the fence at the same time.
The producers might worry about things like databases, the consumers
might worry about front end presentation and reports.
> > autonomy and performance. Middleware is very powerful if used
wisely.
>
> A DBMS is very powerful is used wisely.
>
> >the manager is frightened by CR and we wants a web page so he can
> > show it off to his friends ;-)
> All major report tools (including Crystal) has a web front.
Ok.
> > Maybe but what if they don't allow it. I can't imagine the security
> > team allowing integration with ... well anyone else ;-|
> But your security team will allow your application integrating with a
> Radius Authentication Server?
Something like that.
> > Don't think so. The have explicitly hidden behind firewalls - no
> > access. You want access to our information, here is a limited view
> > via a CORBA object take it or leave it.
> Your firewalls does not know that whether CORBA or something else is
> used.
Some do know about protocols but all know about ports.
If accounts only expose limited ports and MQ or a Corba object happens
to be running on that port what can you do?
> > In large organizations departments do not allow their databases to
be
> > hacked by everyone.
> I never said anything about hacking the database.
No but they did. That is what they don't want.
> Usually a DBMS has a
> very competent security system. It may also be content-aware
(different
> users have different access to different records). What you are
> suggesting is to have one single database user and disable the entire
> security system. I think that is a very bad idea.
In different contexts that is exactly what happens, Mr Apache.
> > We needed to integrate across 60 large systems, can you imagine the
> > complete and utter chaos if everyone was allowed to access
everyone'
> s
> > database directly?
> My idea about good software engineering is that you have different
> databases (catalogs or schemas) for different applications. The
> inter-application communications is limited as far as possible to
> asynonchrous message exchange, data replication or read-only
> operations.
I'm talking about distributed n-tier systems across multiple locations,
in large organisations running all sorts of systems, some with
databases,
some not, some this some that, some OO, some VB, etc etc. Now the CEO
requires a product that really needs a lot of those systems to
inter-operate.
Your idea of good software engineering is too late for those guys. What
do we do now?
> > I'd rather have the encapsulated approach.
> I agree that applications should be encapsulated from each other. But
> you are argueing for encalulation within a single application.
I'm arguing that encapsulation is good within an application (in the
commonly known OOP way) but I'm also suggesting when you have system to
sytem communication that entire applications be encapsulated using
middleware. Rather than communicating directly via sockets, sharing
databases or whatever else.
> Fredrik Bertilsson
> http://butler.sourceforge.net
Cheers,
Alex.
<alex99@medcentral.com.au> wrote in message
news:1111330867.366101.44590@l41g2000cwc.googlegroups.com...
> Daniel Parker wrote:
>> Uncle Bob thinks he knows
>> ("Objects that refer to each other using native language constructs.
> I
>> think this is a very nice logical model for lots and lots of data
>> processing") but he doesn't seem to know what "model" means.
>
> I'm guessing he does know ;-)
>
He knows about UML, being an author of books with UML in the title, and all
that. But the concept of "model" seems to be a little different in UML then
in applied mathematics, statistics, physics, or even economics, and in
particular in relational theory. In UML the concept of "model" seems to be
as ad hoc a construction as any found in applied programming, I don't think
anyone would claim that UML was based on theory. That doesn't mean that ad
hoc is bad, but it does mean that it lacks generality, and in particular
that efforts like MDA based on UML are unlikely to go anywhere outside of
narrow enclaves. But I digress...
Regards,
Daniel Parker
|
|
0 |
|
Daniel
3/20/2005 4:18:31 PM
alex99@medcentral.com.au wrote: > Costin Cozianu wrote: > >>alex99@medcentral.com.au wrote: >> >>>Costin Cozianu wrote: >>> >>> >>>>alex99@medcentral.com.au wrote: >>>> > > > (snip) > > >>>The challenge happens to be limited to functionality that falls >>>squarely within the reach of SQL and so it makes SQL shine. >>> >>>The logic appears to be "if SQL is so good at such a trivial > > example, > >>>then it must also be very good at more substantional examples". > > This is > >>>the problem. Technology does not scale linearly. >>> >> >>It happens like this: if for OO code is so complex to manage almost > > the > >>simplest of relationships ... >> > > > That is the problem, this reasoning assumes linear scalability but this > isn't the case. > > Remember I am addressing your conclusion and not your challenge. > > The challenge focuses on SQL yet somehow the conclusion is far more > general than that. > > You conclude ''In particular this page debunks a pervasive > misconception ... that RelationalModel is *not as good* at > representing "relationships" as object models.'' > > These are general, they apply to information and software > beyond the sphere of DBs and SQL. > > Now consider the internals of a more complex model, say the > internals of a wordprocessor or spreadsheet. > > They have plenty of "many to many" relationships in there. Yet SQL > cannot be used for so much as one of them. > > Don't say this is irrelevant (as you do below). > > Had you limited your conclusion only to the sphere of the challenge > then you may have a point. > > Had you concluded: "SQL provides some useful functionality > that is not easily mimicked by using OOL's and it requires > fewer lines of code to implement some features" then I > would agree with you. > > However since you went on to generalize about the Object Model > then you need to deal with its strengths not just the > particular weakness you have chosen to showcase. > > You wanted to use the challenge to "debunk the misconception that > the ''Relational Model is not as good at representing > "relationships" as Object Models"'' > > Yet when I speak of scenarios that the OM is good at you say they are > irrelevant. > > Costin you cannot have it both ways. Either change your conclusion, > limit it only to the challenge or face the facts that the "RM > implementations are not as good at modeling complex relationships > as the object model" (to use words similar in style to yours). > > >>>I am constantly integrating diverse information sources:- from >>>databases, sockets, XML, LDAP, text files, spreadsheets, Corba, MQ, >>>EJBs, dbmfile's, web pages, email ... >>> >> >>Irrelevant. > > > No. I am within scope of your conclusion where you speak of modeling > relationships. The above technology models relationships and you speak > of the Object Model, which I use for the above where OOP is up to the > task SQL isn't. > > >>>At this level of information management clearly a database and SQL > > is > >>>out of scope and beyond their realm. Something more powerful is >>>required. >> >> >>Non-sense. If you want to call a Ferrari more powerful than a >>Freightliner, it will only betray your ignorance. You can't haul >>trailers with Ferrari, so anybody who claims one "better" than the > > other > >>is just a dumb ignorant. > > > Excuse me I was expecting an intelligent discussion, am I mistaken? > > In your conclusion you used the phrase "not as good" I have used > the word "better" when I needed a negation, fair usage of the > English language I would have thought. > > I am only addressing your conclusion in your own language. > > (Or am I confusing multiple authorship on wiki's?) > > > >>You cannot manage (i.e. conveniently supplant the features provided > > by > >>DBMS) data with OO constructs. And that's the bottom line. What you > > do > >>in the other layers is totally irrelevant. >> >> >>>For me, that something more powerful has been Perl and >>>Java/OOP. >>> >>>Certain OO languages are up to the task, SQL isn't. >>> >>> >> >>No, you can't street race with a Freightliner. You can haul trailers. >> >> >> >>>Costin WROTE: At: http://c2.com/cgi/wiki?ManyToManyChallenge > >>>BEGIN QUOTE >>> >>> >>>>The challenge was intended to demonstrate that SQL has useful >>>>functionality that is not readily available, nor trivially >>>>implementable in OO environments. >>> >>> >>>Agreed, however, I can re-use my OO solution. >>> >> >>The non-existent one that you handwave about it. >> >> >>>(snip) >>> >>> >>> >>>>In particular this page debunks a pervasive misconception >>>>(see quotes ObjectRelationalPsychologicalMismatch) that >>>>RelationalModel is not as good at representing >>>>"relationships" as object models. >>> >>> >>>>Which claim should be judged ridiculous on the face >>>>of it, but it is amusing how many "important names" >>>>in the OO camp make it. >>> >>> >>>END QUOTE >>> >>>Nothing has been debunked. >>> >> >>Posted so long ago and nobody managed to produce codce, hmmm. Call it > > >>what you like, I call it debunking. > > > You win one seat, which I have always acknowledged, then you claim > victory > in the entire election. Nice try. > > >>>Relational technology is good at modeling relationships but only in >>>limited contexts, beyond that you need something more powerful > > (like a > >>>good OOL). >>> >> >>Smacks of marketing brochure speak. Why would anyone give your > > handwaved > >>claim any credence ? > > > The credence to my claim is based on real world systems and they > address relationships and modelling as generally as you do in your > conclusion. > > (Not because I can mimick certain SQL features in less lines > of OOL code as per your challenge). > > Had I contrived a simplistic example that showcases only my > technology of choice and had I dismissed all else as irrelevant > then yes it would smack of brochure speak. > > Thanks for the discussion, > Alex Kay > You're all just brochure speak. If you were expecting an intelligent discussion, you wouldn't be trolling me. You either have something *technical* and *concrete* and *relevant* (claiming that SQL cannot control rocket engines is technically true, but irrelevant to the point of being idiotic), or else this "intelligent" discussion is over.
frebe wrote: > alex99@medcentral.com.au wrote: > > Entity beans in EJB are tied to databases but CORBA and MQ can be > tied > > to anything. > > > > As a developer I'm only suppose to be aware of the agreed upon > > interface. That is the fence that divides me and them. > > It is exactly the same thing this SQL and ODBC/JDBC/ADO. It is an > interface. The implementation can be anything from a simple flat file > framework to a big monster such as Oracle. Hmm, that isn't what I was talking about but I've move on. > Corba has nothing at all to do this data management. It is only a > mechanism for distributing method calls. Can you explain how CORBA > would replace a RDBMS without having to implement all data management > features by yourselft? I didn't say it would replace a RDBMS at all. See my examples below. You asked: > Can you exaplain how you could use Corba, MQ or EJB without a backend > DBMS? I gave you some examples, see below. > MQ may be regarded as data management, but only in a very limited way. > The only supported data structure is the queue and possibly the array. > How would you solve the customer problem I asked you about before, > using MQ? I wouldn't and that's the beauty of it. If the guys talking to me via MQ have a database they would solve it. If they run an old IBM mainframe with a network database and they aren't even running SQL your query wouldn't be of much use to them. Tomorrow if they eventually ditch the dinasour and upgrade their system I don't care I still use the same MQ arrangement my code does not change. EXAMPLES of information sources that are not databases: > > Behind the scene they may have a battery of computers probing every > > telephone exchange in the country via 9600 baud serial connections. > Or > > they may be connected to thousands of routers, switches and network > > devices or it may indeed be a database after all or a bunch of XML > > files ... > > Is this an argument for not using JDBC/ODBC/ADO? Absolutely. I'm surprised you even ask that question. How do I talk to routers with JDBC/ODBC/ADO? They run IOS is there a JDBC interface I'm not aware of? How do I talk to an exchange using JDBC? They don't run SQL. > > I've encountered all of the above but it shouldn't matter to me. I'm > > suppose to be shielded from all that detail. From my experience I can > > say that that indeed was the case. I don't even know what was behind > > some of the MQ sytems? Maybe it was mice peddling on a wheel emitting > > MQ strings ;-) > > All this could be said about SQL too. When a schema changes won't my application need to know about that? When my program looks for table BLAH but someone moved some of that data to table X and the other to Y won't that affect me? > Fredrik Bertilsson > http://butler.sourceforge.net Regards, Alex
alex99@medcentral.com.au wrote: > How do I talk to routers with JDBC/ODBC/ADO? They run IOS is there a > JDBC interface I'm not aware of? The implementation of the JDBC driver can use "anything", including routers, to perform what it is supposed to perform. If you use routers or not is an implementation detail, which is not visible in the interface. > When a schema changes won't my application need to know about that? The schema is a part of the interface. If you change it, your application need to know about that. But the interface to the DBMS (SQL + schema) hides a lot of details, like what indexes is used, how it transactions support implemented, how is locking implemented, etc, etc. If you still want to application to be unaware of a schema change, can you give an example of such change? You can compare to your MQ example. If you change the content of you messages, your application need to know about that. > When my program looks for table BLAH but someone moved some of that data to > table X and the other to Y won't that affect me? Why would someone move the data from one table to another? Fredrik Bertilsson http://butler.sourceforge.net
frebe wrote: > alex99@medcentral.com.au wrote: > > > How do I talk to routers with JDBC/ODBC/ADO? They run IOS is there a > > JDBC interface I'm not aware of? > > The implementation of the JDBC driver can use "anything", including > routers, to perform what it is supposed to perform. If you use routers > or not is an implementation detail, which is not visible in the > interface. Right but the JDBC interface is not applicable to routers. What does select * from ?? mean to a router? The underlying technology doesn't even remind me of a database. The mapping is extremely weak. Besides that your JDBC driver would need to communicate via a Telnet like protocol to a serial port, I know what would be possible, but certainly not very pleasant. This isn't the way I do it all. There are better ways. > > When a schema changes won't my application need to know about that? > > The schema is a part of the interface. If you change it, your > application need to know about that. But the interface to the DBMS (SQL > + schema) hides a lot of details, like what indexes is used, how it > transactions support implemented, how is locking implemented, etc, etc. > > > If you still want to application to be unaware of a schema change, can > you give an example of such change? I thought I did, let me try again. The XYZ department have decided to add a dozen new fields to the customer table for their own purposes. I don't even want them. All I get is an going messages via MQ when purchase orders are raised. The Message I get is something like [purchaseOrderID, customerID, itemID, ...] Why should I have to change my application if they change their tables? Especially when they change fields that don't even affect me. It isn't all about schema changes either. What if they decide to upgrade their network or operating system, database version or whatever why should I have to stop my system which does so many other things for so many other people? I need to keep getting all those exchange tests via Corba I can't afford down time. By using MQ messages from the XYZ department will merely be absent for a while. Meantime I can still continue doing everything else I do it doesn't affect me. When you integrate with many other systems, this is a great advantage. In large environments, someone is always upgrading or changing or doing something that I would like to be shield from. > You can compare to your MQ example. If you change the content of you > messages, your application need to know about that. True if the Message gets changed then yes it will affect me, but usually that is far less of an issue than a database schema change and possible schema migration issues. By interposing certain middleware you do not become totally immune to changes however you are shielded to a greater degree. So some people that sounds trivial, to others it's vital. > > When my program looks for table BLAH but someone moved some of that > data to > > table X and the other to Y won't that affect me? > > Why would someone move the data from one table to another? They decided to normalize it because a kid straight out of college told them about Boyce-Codd normal form. > > Fredrik Bertilsson > http://butler.sourceforge.net Cheers.
Costin Cozianu wrote: > alex99@medcentral.com.au wrote: > > Costin Cozianu wrote: > > > >>alex99@medcentral.com.au wrote: > >> > >>>Costin Cozianu wrote: > >>> > >>> > >>>>alex99@medcentral.com.au wrote: > >>>> SNIP. > You're all just brochure speak. If you were expecting an intelligent > discussion, you wouldn't be trolling me. > You either have something *technical* and *concrete* and *relevant* > (claiming that SQL cannot control rocket engines is technically true, > but irrelevant to the point of being idiotic), or else this > "intelligent" discussion is over. Your reply amazes me. I assure you I am not trolling anyone. Can you spell out if that wiki page is only about the SQL challenge or about relational and object oriented technology in general. The page talks about the general case but here you seem to insist on strict adherence only to the SQL oriented challenge? Which is it, general or SQL specific, please clarify.
Costin Cozianu wrote: > alex99@medcentral.com.au wrote: > > Costin Cozianu wrote: > > > >>alex99@medcentral.com.au wrote: > >> > >>>Costin Cozianu wrote: > >>> > >>> > >>>>alex99@medcentral.com.au wrote: SNIP. > You're all just brochure speak. If you were expecting an intelligent > discussion, you wouldn't be trolling me. > You either have something *technical* and *concrete* and *relevant* > (claiming that SQL cannot control rocket engines is technically true, > but irrelevant to the point of being idiotic), or else this > "intelligent" discussion is over. Your reply amazes me. I assure you I am not trolling anyone. Can you spell out if that wiki page is only about the SQL challenge or about relational and object oriented technology in general. The page talks about the general case but here you seem to insist on strict adherence only to the SQL oriented challenge? Which is it, please clarify.
> Right but the JDBC interface is not applicable to routers. What does > select * from ?? mean to a router? The underlying technology doesn't > even remind me of a database. So why are you talking about routers? The original question I asked you was: "Can you exaplain how you could use Corba, MQ or EJB without a backend DBMS?" Where did the router thing come from? > The XYZ department have decided to add a dozen new fields to the > customer table for their own purposes. I don't even want them. > All I get is an going messages via MQ when purchase orders are raised. > The Message I get is something like [purchaseOrderID, customerID, > itemID, ...] > Why should I have to change my application if they change their tables? > Especially when they change fields that don't even affect me. In this case you don't have to do anything with your application. Adding column in a table doesn't break the interface (in the same way as a new method don't break the interface to a class). If you did "select name, city from customer" before the change, the same statement will return exactly the same data as after the change. Updates and inserts will be unaffected as well. Another solution would also be to create a new table with the new columns but the the same primary key as the original customer table. Is this the best example you could give me? Please give me a better one. (As a matter of fact there are a few valid examples, but they are very rare. Only one guy, so far, at comp.object have been able to give a reasonable example). > What if they decide to upgrade their network or operating system, > database version or whatever why should I have to stop my system which > does so many other things for so many other people? You want to be able to updrade your operating system without having to restart your application? I don't know which of my questions your are trying to answer here, but it still sounds like a silly example. > By using MQ messages from the XYZ department will merely be absent for > a while. Meantime I can still continue doing everything else I do it > doesn't affect me. It would be very easy to implement a JDBC-driver that wraps the original driver and allows the database server to restart. You already have the DBMS encapsulated by a standard interface. You don't have to invent a new interface. > In large environments, someone is always upgrading or changing or doing > something that I would like to be shield from. This is why asynchrous messages should be used for inter-application communication. But inside an application, between the different layers, this is just unnecessary work. >> Why would someone move the data from one table to another? > They decided to normalize it because a kid straight out of college told > them about Boyce-Codd normal form. Ok, schema changes may be done because they did it wrong the first time. But do you really think it is possible to isolate layer A from design flaws in layer B? Normalization will also change the semantics of the schema. Lets say the have a order table with the columns orderid, partno, quantity, customername, customercity. Now we normalize and create a customer table like this: customer (customerid, name, city) order (orderid, partno, quantity, customerid) This kind of change will for sure affect the rest of your application. First you have to change your object domain model, second you have to create a new client form for editing customers and removing the name and city fields from the order form. Fredrik Bertilsson http://butler.sourceforge.net
> That example was about 10 years Maybe RDBMS technology has improved in ten years. I think you should avoid giving performance statistics that are 10 years old. > > The thing is database optimizers, indexes and joins can easily be > > beaten if you think about things. > We did it routinely. Then you would have no problem reproduce such example and sent it to me. >> That is because you don't know what a database is. If your team had >> some developers that knew something about databases, he would let you >> touch it. > Now now Fredrick, how can you make that statement about me you don't > even know who I am. You don't know what knowledge I have about > databases. I only know what you have shown in this debate.... > Nor do you know the dba's and the corporate policy (which is to ban > programmers from touching production systems without exception). We are not debating your company's policy here. I am talking about how a DBA in general should work. >>There are a standard named ANSI SQL. All major database >> vendors supports a very large subset of this standard. > Really, that's news to me. Everytime I use SQL I get bitten by vendor > specifics. I have recently converted a large enterprise application originally written for Informix, to support Oracle and SQL Server as well. 99,99% of the SQL statements are identical for all dialects. > If accounts only expose limited ports and MQ or a Corba object happens > to be running on that port what can you do? Stop using an DBMS is not the answer anyway. > Your idea of good software engineering is too late for those guys. What > do we do now? A bad design will always give you problems. If your company uses the DBMS in a bad way and major changes is not longer possible, you need to do what it takes to make it work. But don't use that experience as an argument for not using a DBMS in new applications. Try to see what mistakes they did, and make sure they (or someone else) don't do it again. Fredrik Bertilsson http://butler.sourceforge.net
frebe wrote: > > Right but the JDBC interface is not applicable to routers. What does > > select * from ?? mean to a router? The underlying technology doesn't > > even remind me of a database. > So why are you talking about routers? The original question I asked you > was: > "Can you exaplain how you could use Corba, MQ or EJB without a backend > DBMS?" Where did the router thing come from? A corba object does not need to be attached to a database of any kind on either side of the interface. Neither does MQ but entity EJB's are designed to work with DBs. Your application <-----> Corba <-------> X Where X can be something like a bunch of routers, telephone exchanges, another corba object, an XML feed... There are no databases in sight. (Although there could be). You use Corba objects the same way whether they are attached to a database or not. You find the object you are interested by using a nameserver like JNDI, you then you attach to the object you want and take it from there. You must have implemented the interface your information supplier expects you to use. MQ's don't need a database on either side of a Q either. I hope I have explained how (and in other posts why) you use Corba and MQ without a RDBMS. Does that answer your question? ---8<--- Snip ----8<---- Sorry I'll snip the rest if we can't get past this point then the rest will probably be meaningless. (Besides that it's really really late and I've gotta go). Cheers.
alex99@medcentral.com.au wrote: > Costin Cozianu wrote: > >>alex99@medcentral.com.au wrote: >> >>>Costin Cozianu wrote: >>> >>> >>>>alex99@medcentral.com.au wrote: >>>> >>>> >>>>>Costin Cozianu wrote: >>>>> >>>>> >>>>> >>>>>>alex99@medcentral.com.au wrote: > > > SNIP. > > >>You're all just brochure speak. If you were expecting an intelligent >>discussion, you wouldn't be trolling me. > > >>You either have something *technical* and *concrete* and *relevant* >>(claiming that SQL cannot control rocket engines is technically true, > > >>but irrelevant to the point of being idiotic), or else this >>"intelligent" discussion is over. > > > Your reply amazes me. I assure you I am not trolling anyone. > > Can you spell out if that wiki page is only about the SQL challenge or > about relational and object oriented technology in general. > > The page talks about the general case but here you seem to insist on > strict adherence only to the SQL oriented challenge? > > Which is it, please clarify. > I don't understand where you get such non-sense as implying that I insist on a non-existent SQL challenge. Using SQL is just one of possible solutions. Other solutions have failed to materialize but a lot of handwaving, including yours have been done instead. The challenge is clearly spelled, it is about providing an interface behind which the client code can manage a typical many to many relationship, under the normal constraints most modern software have to face, including concurrent operation. More than that I do not understand what you want me to clarify.
alex99@medcentral.com.au wrote: > I agreed that DBMSs and SQL provide useful technology (my original post > paragraph 2). > > It would take more lines of code to implement your particular challenge > in an OO language of my choice, yes I agree with that too. > > Yet I have a completely different conclusion. I wonder if the relational guys realize that a relational database can't be implemented without the network model because the computer architecture used to build software is the network model!? Jeff Brooks
Costin Cozianu wrote: .... snip ... > I don't understand where you get such non-sense as implying that I > insist on a non-existent SQL challenge. Using SQL is just one of > possible solutions. Other solutions have failed to materialize but a lot > of handwaving, including yours have been done instead. I propose a new challenge to continue the comparison: Write software that loads, and displays an image. > The challenge is clearly spelled, it is about providing an interface > behind which the client code can manage a typical many to many > relationship, under the normal constraints most modern software have to > face, including concurrent operation. > > More than that I do not understand what you want me to clarify. I think the result of the challenge is OO can do it but it's easier in SQL. Now try my challenge. Jeff Brooks
frebe wrote: > >>There are a standard named ANSI SQL. All major database > >> vendors supports a very large subset of this standard. > > Really, that's news to me. Everytime I use SQL I get bitten by vendor > > specifics. > I have recently converted a large enterprise application originally > written for Informix, to support Oracle and SQL Server as well. 99,99% > of the SQL statements are identical for all dialects. In your SQL statements did you use any of Oracle's date related functions? They where screwed up in version 3, they are still screwed in version 9. Are the Date (and most other) functions part of the ANSI standard?
"Jeff Brooks" <jeff_brooks@nospam.com> wrote in message news:frm%d.743889$8l.287698@pd7tw1no... > alex99@medcentral.com.au wrote: > > I wonder if the relational guys realize that a relational database can't > be implemented without the network model because the computer architecture > used to build software is the network model!? > I don't think relational people care how an RDBMS is implemented, Jeff. Why would you think they might? Regards, Daniel Parker
|
|
0 |
|
Daniel
3/21/2005 2:41:15 AM
Costin Cozianu wrote: > alex99@medcentral.com.au wrote: > > Costin Cozianu wrote: > > > >>alex99@medcentral.com.au wrote: > >> > >>>Costin Cozianu wrote: > >>> > >>> > >>>>alex99@medcentral.com.au wrote: > >>>> > >>>> > >>>>>Costin Cozianu wrote: > >>>>> > >>>>> > >>>>> > >>>>>>alex99@medcentral.com.au wrote: > > > > > > SNIP. > > > > > >>You're all just brochure speak. If you were expecting an intelligent > >>discussion, you wouldn't be trolling me. > > > > > >>You either have something *technical* and *concrete* and *relevant* > >>(claiming that SQL cannot control rocket engines is technically true, > > > > > >>but irrelevant to the point of being idiotic), or else this > >>"intelligent" discussion is over. > > > > > > Your reply amazes me. I assure you I am not trolling anyone. > > > > Can you spell out if that wiki page is only about the SQL challenge or > > about relational and object oriented technology in general. > > > > The page talks about the general case but here you seem to insist on > > strict adherence only to the SQL oriented challenge? > > > > Which is it, please clarify. > > > > > I don't understand where you get such non-sense as implying that I > insist on a non-existent SQL challenge. Using SQL is just one of > possible solutions. Other solutions have failed to materialize but a lot > of handwaving, including yours have been done instead. > > The challenge is clearly spelled, it is about providing an interface > behind which the client code can manage a typical many to many > relationship, under the normal constraints most modern software have to > face, including concurrent operation. > > More than that I do not understand what you want me to clarify. Great thanks for that. So you're only focused on the challenge while I am focussed on everything else on that WIKI page. So our paths don't meet. A typical many to many relationship for me involves "joining" information from different kinds of sources. The definitive corporate user list may be in a passwd file and the (reporting chain) group information may be an XML file. If you put the user's in a database then it gets out of sync with the definitive list. The groups XML file may change in structure, new fields may appear, old ones disappear, new branches or sub-trees may appear. All easily readable to humans and (certain kinds of software) but such a fluid schema doesn't map easily to systems requiring a more rigid schema. Models that use polymorphism and complex interrelationships between objects are also of interest. Nevermind, maybe another time, Alex
"Daniel Parker" <danielaparker@spam?nothanks.windupbird.com> wrote in news:qvq%d.1338$nK.265947@news20.bellglobal.com: > "Jeff Brooks" <jeff_brooks@nospam.com> wrote in message > news:frm%d.743889$8l.287698@pd7tw1no... >> alex99@medcentral.com.au wrote: >> >> I wonder if the relational guys realize that a relational database >> can't be implemented without the network model because the computer >> architecture used to build software is the network model!? >> > I don't think relational people care how an RDBMS is implemented, > Jeff. Why would you think they might? I agree with you that they don't care and I think that's very unfortunate. It leaves them open to legitimate criticisms they can't even understand, let alone respond to. IMHO, Jeff's argument is interesting because its the same one used to blow off Topmind: "If A and B are being compared, then if A subsumes B, B is better." No one really complains about the argument because he values "crappy procedural", but its a different story when used to attack the "holy relational model". Or more concretely, someone could point out that (1) whatever RDBMS features I need I can do in OO and still have my cake and eat it too, or (2) if an RDBMS has to be implemented in a non-relational language, then is the relational model as universally powerful as it claims to be? IMHO both (1) and (2) have failed to produce healthy discussion. The relational debaters cannot appreciate the profound depths of the "attack" and thus fail to question and challenge themselves, while the OO debaters congratulate themselves on an easy "winning point" and continue to settle for languages that completely fail to support persistence and especially transactions "natively". Everyone loses. I must admit that I'm only mentioning these two arguments and don't wish to go to war to debate them. I find them interesting in theory but I've never learned much from the ensuing discussion. I think (1) is weak because no one in their right mind is going to re- implement an RDBMS in OO so they can access it "natively" in their OO language. Its not worth the man-years required and it is man-years. Rather, we'll use the RDBMS for the 80% value it provides then use OO for the other 20% it cannot. (Change the quantities any way you want as long as you don't use 100%/0%.) OTOH, I think (2) is a very interesting issue and it is applicable in dismissing, say, Costin. Because many of us doing OO *are* doing things equivalent to implementing an RDBMS and his angry arrogance prevents him from saying anything remotely useful to that group of us. Personally I have a couple of satisfactory solutions for bridging OO and RDBMS, so I'm no longer religious. But I am also academically interested in searching for that holy grail. I've programmed part of the relational model in OO as an exercise. It was interesting, although I didn't go very far down the path. What I found was that I never used the relational tools I did develop. Not because I failed to take them far enough to be useful; rather I always had a better way to accomplish the same task. In concrete terms my utilities have evolved to contain a substantial bunch of HashMapOfHashMap, HashMapOfSet, HashMapOfHashMapOfSet et al. java objects that everyone in the company uses (and was surprised at how useful they are, despite their ridiculous names :-), and my relational package has been untouched for years. The fact was that no one (this is ime, of course, let us know if ymv) actually finds "relational objects" to be *useful* in their OO applications. That was a valuable discovery more important than intellectual debates. (Caveat: I do have a package with DBase, Table, Row, Column, Index, etc, objects that I use to build and manage RDBMSs, but these are behind the scenes objects for converting a schema to an actual database, generating the CRUD SQL strings, lazy creation of procedures, and dealing with vendor SQL implementation discrepancies. Aside: Whoever said the major RDBMSs are 99+% identical is absolutely wrong. DB2, SQLServer, Oracle and HSQL are riddled with differences and it took a lot of annoying work to support them all programmatically. Its not just the procedures, try *creating* a database in each of these RDBMSs from some common schema if you don't believe me.)
|
|
0 |
|
Rich
3/21/2005 4:13:06 AM
alex99@medcentral.com.au wrote: > In your SQL statements did you use any of Oracle's date related > functions? They where screwed up in version 3, they are still screwed > in version 9. > Are the Date (and most other) functions part of the ANSI standard? We avoided using date functions as far as possible. In case we could not avoid them, we created custom stored procedures for date manipulation, that behaived the same in all types of databases. Fredrik Bertilsson http://butler.sourceforge.net
frebe wrote: > alex99@medcentral.com.au wrote: > > In your SQL statements did you use any of Oracle's date related > > functions? They where screwed up in version 3, they are still screwed > > in version 9. > > Are the Date (and most other) functions part of the ANSI standard? > > We avoided using date functions as far as possible. In case we could > not avoid them, we created custom stored procedures for date > manipulation, that behaived the same in all types of databases. Great thanks for that, I had never seriously contemplated doing it that way. I'll look into it. And I forgot to ask about SEQUENCES or AUTO_INCREMENT, how do you do that in Oracle and how do you do that in SQL Server? > Fredrik Bertilsson > http://butler.sourceforge.net
> I hope I have explained how (and in other posts why) you use > > Corba and MQ without a RDBMS. But you were argueing that Corba and MQ could replace a RDBMS. How is this possible? Fredrik Bertilsson http://butler.sourceforge.net
I'm kinda comming into the discussion a bit late, so I appologize if I
reiterate points already made, but here goes.
First I completely disagree with the idea that if we only had enough
persistant ram we wouldn't want or need a relational store. Its rather
about choosing the correct tool for the task at hand. If you have a
nail use a hammer if you have a screw use a screw-driver. SQL is
designed to store and query large sets of structured data. Howerver, it
isn't ideally suited for complex calculations or polymorphic behavior.
So you've figured out how to prersist users/groups and their
relationships in a database without any OO code... well done what do
you indend to do with it? I assume you are storing this data because
you want to do something with it, correct? Perhaps this data is used
to "authorize" a user for a specific task? perhaps they need they need
to be a member of the "Lender" group before they are allowed to approve
a loan application? Simple enough we can query if the user is IN
('Lender') before allowing them do anything with Loan tables. But lets
complicate things a bit shall we? We decide we that simple groups are
not sufficient we need a bit more granularity so we want to assign
"rights" such as 'Approve Loan' to a user OR a group and allow groups
to contain groups to make management of user rights easier.
Now give me a simple query that can be used to determine if the user
has the "Approve Loan" right granted directly to the user or any groups
he is a member of and any groups those groups might be a member of...
also remember that deny overrides any grant at any level).
Lets add a bit more type dependant (polymorphic) functionality shall
we... Our fictitious lender offers many different types of loans, home
loans have greater risk so not all users that can approve a loan can
approve all types of loans we have decided to create permissions for
different types of loans and/or the value of the loan... home loans
require explicit approval by a user with the "Approve Home Loan" right,
otherwise "Approve Loan" permission is good enough.
While your at it I (roleplaying customer) need an amoritization
schedule (the loan applicaiton has the principal loan amount, annual
interest rate, loan duration and payment schedule (monthly, quarterly,
weekly, etc)). If you can write an sproc or PL/SQL script for me to do
that would be cool then I don't need to waste our presious network
resources to transmit the loan objects to the application tier.
I think your on to something with this SQL approach, we can give all
our loan reps a Query Analyzer and if they want to create a loan
application they can just type exec sp_createLoan('... oh wait customer
first exec sp_createCustomer('first.. wait I think last name goes
first... well nevermind guess we to create a gui of some sort
perhaps... what language did they use to create Query Analyzer (or the
database engine for that matter)? I guess we need a high level
language for somethings, ah well. The amoritization schedule you can
still do for me right? and you've already got me convinced the db is
the best place for this user/group thing, the additional complexity
isn't to much for you is it?
And about this thread saftey issue... I guess we don't need to worry to
much about thread synchronization at the database level but I'm a bit
concerned about multiple users working with the same data at the same
time. I was reading something the other day about 'dirty data' and
'phantom data' such as when a user inserts a row and then another user
reads that row and then the user that inserted that row aborts his
transaction, are you familiar with this? I checked the docs and by
default SQL does not prevent phantom data! I guess they have provided
an issolation level called serializable that prevents phantom data but
the documentation says "use only when necessary." When do you suppose
this is necessary? I don't want to generate a report and send it off
for funding that that says we have approved a loan when that loan
approval hasn't even been commited yet! I'm torn about this
user/group/right scenario though, do you think we need to be concerned
about dirty data and phantom reads?
Suppose we create this gui application and this application allows the
administrator to change the user right assignments by checking a few
boxes or something and then save his changes, I guess it probably would
replace the existing options with the ones he is viewing right? so if
he perhaps checks the deny on the 'approve home loan' box and another
administrator was told to grant him permission to 'approve auto loan',
last person to save wins right and he would still be authorized to
approve home loans? I guess we could just keep the transaction open
with serializable issolation the entire time the administrator is
viewing those options so that the second admin isn't even allowed to
view the data until the first admin finishes... but if we do that we
may not be able to approve other users actions either and are entire
system could come to a halt waiting on this one admin. I was looking
into some alternatives, what do you think about optimistic concurrency
control? this doesn't seem to be a 'native' database feature. Its
rather simplistic in theory though, when you read the data you also
include a version number and then when you do the update you include
that same version number if it changed then you know its been modified
by someone else, so the only lock that we need in this scenerio is
during the update. What was it again in high-level languages you found
difficult (ArrayList.Synchronized method)?
Anyways, relational storage wont be going away anytime soon perhaps
never, the decomposition of the data makes it possible to construct
very effecient queries over large sets of data. Currently searching
object graphs is more difficult and less efficient then it could be,
for example searching for all customers located in 'AZ' its not to
write a foreach loop, however it gets old and its somewhat hard-coded
making arbitrary queries more difficult to implement efficiently, I
suspect someday technologies like XQuery might become a native part of
the language allowing easy creation of arbitrary queries on object
graphs. Memory managers probably need some work in this area as well,
ts not very efficient to query object graphs compared to a database,
primarily because of the way that memory is allocated, objects are
allocated onto the heap in a somewhat arbitrary location based on how
much data you want to allocate and what it has available, there is no
gaurantee that objects of the same type will be located remotely close
to each other in memory or in memory at all (paged to disk), so a
statment like foreach customer in getcustomers() { if
customer.address.state = "AZ" list.add(customer); } could result in
lots of memory paging. The database manages the memory much
differently loading records of the same type close together in "pages"
with fixed record lengths allowing quick navigation from one address
record to the next address record. I suspect someday heap allocation
for objects might become more optimized for querying done more like a
database where objects of the same type will be allocated in the same
location (inheritance I'm sure complicates this but perhaps some form
of replication of base class properties as one might denormalize a
database could work but I'm not an expert on that kinda thing anyway).
Databases however are learning to work better with (not to eliminate)
OO apps, in a way that is more object graph friendly, SQL 2005 will
allow multiple active result sets or xml resultsets provide ways make
it easier to read an object and its children in one step from multiple
tables simultaniously rather then needing to read all customer data
then go back to each customer previously read to add the address
record. Asynchronous notification makes it possible to be informed
when things change rather then needing to repeadedly read the database
to ensure you are most up to date. SQL 2005 has some useful features
to help bridge the gap between OO and relational, each tool has a
purpose neither trying to elimiate the other just the gap, the goal is
rather to get "seamless integration" so they play nice giving the
developer the most productive tool for the current task without having
to pick one or the other and/or become a bridge builder.
- Kurt
kurbylogicfrebe wrote: > > I hope I have explained how (and in other posts why) you use > > > Corba and MQ without a RDBMS. > > But you were argueing that Corba and MQ could replace a RDBMS. How is > this possible? Hmm, I don't think we have communicated very clearly, maybe a review of my examples might help? I never said anything about replacement, they do not replace RDBMS, I said they can be used to encapsulate other information systems. What those other information systems are can vary greatly. I can't see how encapsulation could be confused with replacement. If I go on again here I'll only be repeating myself so I'll leave it at that ;-) Cheers. > Fredrik Bertilsson > http://butler.sourceforge.net
> I never said anything about replacement In the start of this debate you said: "Think MiddleWare. Corba, MQ, EJB, XML, web, ... All these puppies can handle information too, databases aren't the only show in town ;-) " Fredrik Bertilsson http://butler.sourceforge.net
alex99@medcentral.com.au wrote: > Costin Cozianu wrote: > >>alex99@medcentral.com.au wrote: >> >>>Costin Cozianu wrote: >>> >>> >>>>alex99@medcentral.com.au wrote: >>>> >>>> >>>>>Costin Cozianu wrote: >>>>> >>>>> >>>>> >>>>>>alex99@medcentral.com.au wrote: >>>>>> >>>>>> >>>>>> >>>>>>>Costin Cozianu wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>alex99@medcentral.com.au wrote: >>> >>> >>>SNIP. >>> >>> >>> >>>>You're all just brochure speak. If you were expecting an > > intelligent > >>>>discussion, you wouldn't be trolling me. >>> >>> >>>>You either have something *technical* and *concrete* and *relevant* >>>>(claiming that SQL cannot control rocket engines is technically > > true, > >>> >>>>but irrelevant to the point of being idiotic), or else this >>>>"intelligent" discussion is over. >>> >>> >>>Your reply amazes me. I assure you I am not trolling anyone. >>> >>>Can you spell out if that wiki page is only about the SQL challenge > > or > >>>about relational and object oriented technology in general. >>> >>>The page talks about the general case but here you seem to insist > > on > >>>strict adherence only to the SQL oriented challenge? >>> >>>Which is it, please clarify. >>> >> >> >>I don't understand where you get such non-sense as implying that I >>insist on a non-existent SQL challenge. Using SQL is just one of >>possible solutions. Other solutions have failed to materialize but a > > lot > >>of handwaving, including yours have been done instead. >> >>The challenge is clearly spelled, it is about providing an interface >>behind which the client code can manage a typical many to many >>relationship, under the normal constraints most modern software have > > to > >>face, including concurrent operation. >> >>More than that I do not understand what you want me to clarify. > > > Great thanks for that. So you're only focused on the challenge while I > am focussed on everything else on that WIKI page. So our paths don't > meet. > > A typical many to many relationship for me involves "joining" > information from different kinds of sources. The definitive corporate > user list may be in a passwd file and the (reporting chain) group > information may be an XML file. > > If you put the user's in a database then it gets out of sync with the > definitive list. > > The groups XML file may change in structure, new fields may appear, old > ones disappear, new branches or sub-trees may appear. All easily > readable to humans and (certain kinds of software) but such a fluid > schema doesn't map easily to systems requiring a more rigid schema. > > Models that use polymorphism and complex interrelationships between > objects are also of interest. > > Nevermind, maybe another time, > Alex > Whatever. Think ofn solving the challenge as a pre-condition to discuss anything else, including the non-sense you're worried about.
> And I forgot to ask about SEQUENCES or AUTO_INCREMENT, how do > you do that in Oracle and how do you do that in SQL Server? We don't use sequences. It is rather easy to implement this feature in the application instead. Fredrik Bertilsson http://butler.sourceforge.net
kurbylogic@hotmail.com wrote:
> I'm kinda comming into the discussion a bit late, so I appologize if I
> reiterate points already made, but here goes.
>
> First I completely disagree with the idea that if we only had enough
> persistant ram we wouldn't want or need a relational store. Its rather
> about choosing the correct tool for the task at hand. If you have a
> nail use a hammer if you have a screw use a screw-driver. SQL is
> designed to store and query large sets of structured data. Howerver, it
> isn't ideally suited for complex calculations or polymorphic behavior.
>
>
Ahem, you're right about complex calculation, not about "polymorphic
behavior" -- there's no such thing.
> So you've figured out how to prersist users/groups and their
> relationships in a database without any OO code... well done what do
> you indend to do with it? I assume you are storing this data because
> you want to do something with it, correct? Perhaps this data is used
> to "authorize" a user for a specific task? perhaps they need they need
> to be a member of the "Lender" group before they are allowed to approve
> a loan application? Simple enough we can query if the user is IN
> ('Lender') before allowing them do anything with Loan tables. But lets
> complicate things a bit shall we?
Sure, let's. On the other hand, I shall not commit the imprudence of
debating complex things until the simple ones have not been settled.
> We decide we that simple groups are
> not sufficient we need a bit more granularity so we want to assign
> "rights" such as 'Approve Loan' to a user OR a group and allow groups
> to contain groups to make management of user rights easier.
>
> Now give me a simple query that can be used to determine if the user
> has the "Approve Loan" right granted directly to the user or any groups
> he is a member of and any groups those groups might be a member of...
> also remember that deny overrides any grant at any level).
>
Well, that is rather for the more sophisticated and well read DB guru.
However, technically it's not big deal after all.
It boils down to
SELECT right FROM TC_GROUPS tc JOIN GROUP_RIGHTS gr ON (tc.in_group_id=
gr.group_id)
WHERE tc.group_id IN
(SELECT group_id from users_groups ug WHERE ug.user_id= :user_id))
AND right='Approve Loan';
Where TC_GROUPS(group_id, in_group_id) is the transitive closure of
group membership, the only relevant problem remaining being the
maintenance of transitive closure. This is left as an exercise for the
reader.
But before asking me to post a complete solution, could I see the OO
counterpart ?
> Lets add a bit more type dependant (polymorphic) functionality shall
> we... Our fictitious lender offers many different types of loans, home
> loans have greater risk so not all users that can approve a loan can
> approve all types of loans we have decided to create permissions for
> different types of loans and/or the value of the loan... home loans
> require explicit approval by a user with the "Approve Home Loan" right,
> otherwise "Approve Loan" permission is good enough.
>
>
That is rather trivial.
> While your at it I (roleplaying customer) need an amoritization
> schedule (the loan applicaiton has the principal loan amount, annual
> interest rate, loan duration and payment schedule (monthly, quarterly,
> weekly, etc)). If you can write an sproc or PL/SQL script for me to do
> that would be cool then I don't need to waste our presious network
> resources to transmit the loan objects to the application tier.
>
Surely you don't mean to say that loan rates, amortizations, etc. are
"complex calculations" ?
>
> I think your on to something with this SQL approach, we can give all
> our loan reps a Query Analyzer and if they want to create a loan
> application they can just type exec sp_createLoan('... oh wait customer
> first exec sp_createCustomer('first.. wait I think last name goes
> first... well nevermind guess we to create a gui of some sort
> perhaps... what language did they use to create Query Analyzer (or the
> database engine for that matter)? I guess we need a high level
> language for somethings, ah well.
I guess you might be missing here that PL/SQL is a pretty high level
language, and especially with regards to distinguishing positional
parameters is better designed than java or C# or C++, because in PL_SQL
you can just say
sp_xxx(
....
first_name => 'Costin',
last_name => 'Cozianu',
....
);
whereas in most OO languages you simply cannot name your parameters. I
guess this is an instance of ignorant irony that backfires.
> The amoritization schedule you can
> still do for me right?
Right, but only after I'll have decided you're not an incompetent troll.
Given the quality of portions of your post, I am rather suspicious.
> and you've already got me convinced the db is
> the best place for this user/group thing, the additional complexity
> isn't to much for you is it?
>
>
> And about this thread saftey issue... I guess we don't need to worry to
> much about thread synchronization at the database level but I'm a bit
> concerned about multiple users working with the same data at the same
> time. I was reading something the other day about 'dirty data' and
> 'phantom data' such as when a user inserts a row and then another user
> reads that row and then the user that inserted that row aborts his
> transaction, are you familiar with this? I checked the docs and by
> default SQL does not prevent phantom data! I guess they have provided
> an issolation level called serializable that prevents phantom data but
> the documentation says "use only when necessary." When do you suppose
> this is necessary? I don't want to generate a report and send it off
> for funding that that says we have approved a loan when that loan
> approval hasn't even been commited yet! I'm torn about this
> user/group/right scenario though, do you think we need to be concerned
> about dirty data and phantom reads?
> Suppose we create this gui application and this application allows the
> administrator to change the user right assignments by checking a few
> boxes or something and then save his changes, I guess it probably would
> replace the existing options with the ones he is viewing right? so if
> he perhaps checks the deny on the 'approve home loan' box and another
> administrator was told to grant him permission to 'approve auto loan',
> last person to save wins right and he would still be authorized to
> approve home loans? I guess we could just keep the transaction open
> with serializable issolation the entire time the administrator is
> viewing those options so that the second admin isn't even allowed to
> view the data until the first admin finishes... but if we do that we
> may not be able to approve other users actions either and are entire
> system could come to a halt waiting on this one admin. I was looking
> into some alternatives, what do you think about optimistic concurrency
> control? this doesn't seem to be a 'native' database feature. Its
> rather simplistic in theory though, when you read the data you also
> include a version number and then when you do the update you include
> that same version number if it changed then you know its been modified
> by someone else, so the only lock that we need in this scenerio is
> during the update.
I guess you are more confused about the above scenario.
If an admin takes away one user's right after that user has already
performed an action it was previously authorized for, but no longer
subsequently, then the action stays. The session that needs to be
working under "serializable" is that of the user, not that of the admin.
Just because you've read about "optimistic concurrency" in some
"popularization of science" books (I know how some OO circles felt in
love with the idea) doesn't mean you understand the issues. And given
how you framed the above problem I suspect a reading from a more serious
book (like "Transactional Information Systems")would help you think
about these types of problems in a much sounder way.
> What was it again in high-level languages you found
> difficult (ArrayList.Synchronized method)?
>
>
What was that you found easy ?
Did you find it easy to deadlock, or did you find it easy to arrive at
inconsistent results inspite going through all kinds of locks ?
>
> Anyways, relational storage wont be going away anytime soon perhaps
> never, the decomposition of the data makes it possible to construct
> very effecient queries over large sets of data. Currently searching
> object graphs is more difficult and less efficient then it could be,
> for example searching for all customers located in 'AZ' its not to
> write a foreach loop, however it gets old and its somewhat hard-coded
> making arbitrary queries more difficult to implement efficiently, I
> suspect someday technologies like XQuery might become a native part of
> the language allowing easy creation of arbitrary queries on object
> graphs. Memory managers probably need some work in this area as well,
> ts not very efficient to query object graphs compared to a database,
> primarily because of the way that memory is allocated, objects are
> allocated onto the heap in a somewhat arbitrary location based on how
> much data you want to allocate and what it has available, there is no
> gaurantee that objects of the same type will be located remotely close
> to each other in memory or in memory at all (paged to disk), so a
> statment like foreach customer in getcustomers() { if
> customer.address.state = "AZ" list.add(customer); } could result in
> lots of memory paging. The database manages the memory much
> differently loading records of the same type close together in "pages"
> with fixed record lengths allowing quick navigation from one address
> record to the next address record. I suspect someday heap allocation
> for objects might become more optimized for querying done more like a
> database where objects of the same type will be allocated in the same
> location (inheritance I'm sure complicates this but perhaps some form
> of replication of base class properties as one might denormalize a
> database could work but I'm not an expert on that kinda thing anyway).
> Databases however are learning to work better with (not to eliminate)
> OO apps, in a way that is more object graph friendly, SQL 2005 will
> allow multiple active result sets or xml resultsets provide ways make
> it easier to read an object and its children in one step from multiple
> tables simultaniously rather then needing to read all customer data
> then go back to each customer previously read to add the address
> record. Asynchronous notification makes it possible to be informed
> when things change rather then needing to repeadedly read the database
> to ensure you are most up to date. SQL 2005 has some useful features
> to help bridge the gap between OO and relational, each tool has a
> purpose neither trying to elimiate the other just the gap, the goal is
> rather to get "seamless integration" so they play nice giving the
> developer the most productive tool for the current task without having
> to pick one or the other and/or become a bridge builder.
>
> - Kurt
>
Nice deluge of irrelevant 2c that I cannot make any sense of. I'd rather
recommend to you and all contributors to this thread to stay strictly
technical and within your areas of competence, refraining from
unwarranted speculations.
For example it would have helped if rather than being unsubtly ironic
about stuff you think databases cannot handle, you would have tried a
more prudent tone along the lines "In my experience, I found difficult
addressing this kind of issues". Because it may turn out that irony
backfires and bites you somewhere unpleasant .
And again, before complicating this challenge to no end, I'd rather see
the response to the simple challenge, and it would also help if
proponents of new challenges would have already worked out one solution
using their technology/approach of their choice so that they can post it
and/or estimate the complexity, rather than playing it for a sport.
Rich MacDonald wrote: > "Daniel Parker" <danielaparker@spam?nothanks.windupbird.com> wrote in > news:qvq%d.1338$nK.265947@news20.bellglobal.com: > > > I don't think relational people care how an RDBMS is implemented, > > Jeff. Why would you think they might? > > I agree with you that they don't care and I think that's very > unfortunate. It leaves them open to legitimate criticisms they can't even > understand, let alone respond to. Uh huh. The whole point of an RDBMS is that it provides a logical entry point to data. The physical implementation is as irrelevent as is the physical implementation of an OO interface. Statements like "How can OO be worse than a RDBMS when it's model is powerful enought to build one?" -- Jeff Brooks are literally incomprehensible, not just to relational people, but to anyone capable of thought. What does "worse" mean? What does "powerful" mean? Such statements are meaningless. RDBMS implementations are written in computer languages, and that's about all that you can say about it. > > IMHO, Jeff's argument is interesting because its the same one used to > blow off Topmind: "If A and B are being compared, then if A subsumes B, B > is better." No one really complains about the argument because he values > "crappy procedural", but its a different story when used to attack the > "holy relational model". Topmind likes to make statements purporting to compare OO for application development and relational databases for data management. Alfredo also sometimes makes statements that seem to suggest that a great deal of what we commonly regard as application code properly belongs in the database. These statements are not typical of commentary by relational people. The most Date will say is "I'd just like to make it clear that my criticisms of objects and 'object orientation' have always been aimed at their usefulness or otherwise in a database context and not necessarily in any other." And Pascal, "My criticism of OO is purely as a database management technology. I have little to say about it as a programming approach, because that's neither my interest, nor my expertise." > Or more concretely, someone could point out that (1) whatever RDBMS > features I need I can do in OO and still have my cake and eat it too, What does that mean? Let's say you implement some of Uncle Bob's "Objects that refer to each other using native language constructs ... a very nice logical model for lots and lots of data processing." Is that the RDBMS features you have in mind? Or maybe you want to implement transactioning? I know that all all of the OO database vendors have screwed that up on their early attempts, and some of them have never gotten it right. But you can do that, right? Now you want to use a third party report writer. Well, you can do that. You can write an ODBC or JDBC driver in your OOPL that implements an interface for SQL or stored procedures going against Uncle Bob's "unencapsulated data structures without significant methods." But you see what you've done? You've expoited the relational paradigm to allow your "unencapsulated data structure" to be used by a third party tool that doesn't know anything at all about your structures. > or > (2) if an RDBMS has to be implemented in a non-relational language, then > is the relational model as universally powerful as it claims to be? God help us, words without meaning, whatever happened to the language? What claims? Powerful, in what sense? What would an algeraic model of data sensibly aspire to here? > > IMHO both (1) and (2) have failed to produce healthy discussion. The > relational debaters cannot appreciate the profound depths of the > "attack" Why would you think so? OO is easy. Cardelli's "Theory of Objects" is easy. The concept of an ADT is easy. Java and C# OOPL's are easy. Programming in these languages is easy. Design Pattern's is easy. C++ is hard, but only because of the nature of the language, nothing to do with OO. > and thus fail to question and challenge themselves, while the OO > debaters congratulate themselves on an easy "winning point" I think the "winning points" that you're referring to are what I regard as meaningless statements. > and continue > to settle for languages that completely fail to support persistence and > especially transactions "natively". Everyone loses. If you need transactions, you don't want to roll that yourself, not if you can avoid it. This isn't an RDBMS issue per se, but usually the easiest way to support transactioning is to piggy back on a DBMS. But MQ supports transactioning, Tibco supports transactioning, other frameworks support transactioning. > > I must admit that I'm only mentioning these two arguments and don't wish > to go to war to debate them. I find them interesting in theory but I've > never learned much from the ensuing discussion. Read Dmitry's posts, Dmitry makes sense. > > I think (1) is weak because no one in their right mind is going to re- > implement an RDBMS in OO so they can access it "natively" in their OO > language. Its not worth the man-years required and it is man-years. > Rather, we'll use the RDBMS for the 80% value it provides then use OO for > the other 20% it cannot. (Change the quantities any way you want as long > as you don't use 100%/0%.) > > OTOH, I think (2) is a very interesting issue and it is applicable in > dismissing, say, Costin. Because many of us doing OO *are* doing things > equivalent to implementing an RDBMS and his angry arrogance prevents him > from saying anything remotely useful to that group of us. A relational database is fundumentally about a logical model of data. The value of that model depends upon standards. That's why SQL is important even though it's far from the best implementation of the relational calculus. > > Personally I have a couple of satisfactory solutions for bridging OO and > RDBMS, so I'm no longer religious. But I am also academically interested > in searching for that holy grail. I've programmed part of the relational > model in OO as an exercise. It was interesting, although I didn't go very > far down the path. What I found was that I never used the relational > tools I did develop. In my C++ (years ago), C (more years ago), C#, Java application code I use hash tables, red black trees, custom collection classes, or whatever's appropriate. If I want all the trades that have this currency and mature before that date and belong to that portfolio, I query against the relational database, I don't need to keep that in memory and query against the memory. Divide and conquer. > > Aside: Whoever said the major > RDBMSs are 99+% identical is absolutely wrong. DB2, SQLServer, Oracle and > HSQL are riddled with differences and it took a lot of annoying work to > support them all programmatically. Its not just the procedures, try > *creating* a database in each of these RDBMSs from some common schema if > you don't believe me.) The world is full of tools that will allow you to express your database in an ER tool and generate a physical model targeting a specific vendor and version. Regards, Daniel Parker
Costin Cozianu wrote: > alex99@medcentral.com.au wrote: > > Costin Cozianu wrote: > > > >>alex99@medcentral.com.au wrote: > >> > >>>Costin Cozianu wrote: > >>> > >>> > >>>>alex99@medcentral.com.au wrote: > >>>> > >>>> > >>>>>Costin Cozianu wrote: > >>>>> > >>>>> > >>>>> > >>>>>>alex99@medcentral.com.au wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>>Costin Cozianu wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>alex99@medcentral.com.au wrote: > >>> > >>> > >>>SNIP. > >>> > >>> > >>> > >>>>You're all just brochure speak. If you were expecting an > > > > intelligent > > > >>>>discussion, you wouldn't be trolling me. > >>> > >>> > >>>>You either have something *technical* and *concrete* and *relevant* > >>>>(claiming that SQL cannot control rocket engines is technically > > > > true, > > > >>> > >>>>but irrelevant to the point of being idiotic), or else this > >>>>"intelligent" discussion is over. > >>> > >>> > >>>Your reply amazes me. I assure you I am not trolling anyone. > >>> > >>>Can you spell out if that wiki page is only about the SQL challenge > > > > or > > > >>>about relational and object oriented technology in general. > >>> > >>>The page talks about the general case but here you seem to insist > > > > on > > > >>>strict adherence only to the SQL oriented challenge? > >>> > >>>Which is it, please clarify. > >>> > >> > >> > >>I don't understand where you get such non-sense as implying that I > >>insist on a non-existent SQL challenge. Using SQL is just one of > >>possible solutions. Other solutions have failed to materialize but a > > > > lot > > > >>of handwaving, including yours have been done instead. > >> > >>The challenge is clearly spelled, it is about providing an interface > >>behind which the client code can manage a typical many to many > >>relationship, under the normal constraints most modern software have > > > > to > > > >>face, including concurrent operation. > >> > >>More than that I do not understand what you want me to clarify. > > > > > > Great thanks for that. So you're only focused on the challenge while I > > am focussed on everything else on that WIKI page. So our paths don't > > meet. > > > > A typical many to many relationship for me involves "joining" > > information from different kinds of sources. The definitive corporate > > user list may be in a passwd file and the (reporting chain) group > > information may be an XML file. > > > > If you put the user's in a database then it gets out of sync with the > > definitive list. > > > > The groups XML file may change in structure, new fields may appear, old > > ones disappear, new branches or sub-trees may appear. All easily > > readable to humans and (certain kinds of software) but such a fluid > > schema doesn't map easily to systems requiring a more rigid schema. > > > > Models that use polymorphism and complex interrelationships between > > objects are also of interest. > > > > Nevermind, maybe another time, > > Alex > > > > > Whatever. Think ofn solving the challenge as a pre-condition to discuss > anything else, including the non-sense you're worried about. That's your position fair enough but that non-sense is exactly what I have to implement this week ;-| I need to implement a many to many relationship with users and groups where the definitive user list is a unix password file and groups are something else. My application is using Oracle with Java. I know some databases can tie tables to text files. I wonder if an Oracle (v9.2) table can be tied to a unix password file? I'm sure I'll solve the problem somehow but everything I can think of right now is ugly. I wonder how I should proceed? 1. Tie a table to a file? (that would be nice). 2. Write a service (like a daemon) that watches for changes in the password file and then syncs it with the DB User file? 3. Something else? My question amounts to I need a solution to this variation of the challenge. I don't care how many lines it takes as long as I can implement it in 2 days or less, either in Java or Oracle/SQL. I'm not sure if Costin is interested in helping but can he or anyone else help? Thanks, Alex. PS. comp.object is great for OO but for the future, is there another equivalent (ie good) news group for these types of questions comp.integration.nightares.maybe?
>>>Nevermind, maybe another time, >>>Alex >>> >> >> >>Whatever. Think ofn solving the challenge as a pre-condition to > > discuss > >>anything else, including the non-sense you're worried about. > > > That's your position fair enough but that non-sense is exactly what I > have to implement this week ;-| > > I need to implement a many to many relationship with users and groups > where the definitive user list is a unix password file and groups are > something else. My application is using Oracle with Java. > > I know some databases can tie tables to text files. I wonder if an > Oracle (v9.2) table can be tied to a unix password file? > > I'm sure I'll solve the problem somehow but everything I can think of > right now is ugly. I wonder how I should proceed? > > 1. Tie a table to a file? (that would be nice). > 2. Write a service (like a daemon) that watches for changes in the > password file and then syncs it with the DB User file? > 3. Something else? > > My question amounts to I need a solution to this variation of the > challenge. I don't care how many lines it takes as long as I can > implement it in 2 days or less, either in Java or Oracle/SQL. > > I'm not sure if Costin is interested in helping but can he or anyone > else help? > > Thanks, > Alex. > > PS. comp.object is great for OO but for the future, is there another > equivalent (ie good) news group for these types of questions > comp.integration.nightares.maybe? > Well, you haven't exactly specified the Unix system, but what I'd do is consider the database the definitive source of data (because it simply makes more sense), and have the Unix look up the users and groups against Oracle. You can do that certainly with Linux, including using LDAP module or rolling your own. Or yet another solution, if you really want to have the Unix system behave independently, replace the suer management utilities on the system with your own that both invoke the normal utility and send data addition/modification/removals to Oracle.
alex99@medcentral.com.au wrote in news:1111429151.946988.158930 @l41g2000cwc.googlegroups.com: > I need to implement a many to many relationship with users and groups > where the definitive user list is a unix password file and groups are > something else. My application is using Oracle with Java. > > I know some databases can tie tables to text files. I wonder if an > Oracle (v9.2) table can be tied to a unix password file? > > I'm sure I'll solve the problem somehow but everything I can think of > right now is ugly. I wonder how I should proceed? > > 1. Tie a table to a file? (that would be nice). > 2. Write a service (like a daemon) that watches for changes in the > password file and then syncs it with the DB User file? > 3. Something else? I would probably go ahead and do (2) if I was in a hurry and was risk- averse. You could try defining an Oracle table then using procedures to access it. In your procedures you check the user file to see if the date has changed and recalculate the table if needed.
|
|
0 |
|
Rich
3/21/2005 8:56:37 PM
"Daniel Parker" <danielaparker@hotmail.com> wrote in news:1111429065.834515.138200@o13g2000cwo.googlegroups.com: RDBMS is from Mars and OO is from Venus.
|
|
0 |
|
Rich
3/21/2005 9:03:12 PM
"Rich MacDonald" <rich@@clevercaboose.com> wrote in message news:Xns962099ABBFA60richclevercaboosecom@24.94.170.87... > "Daniel Parker" <danielaparker@hotmail.com> wrote in > news:1111429065.834515.138200@o13g2000cwo.googlegroups.com: > > RDBMS is from Mars and OO is from Venus. I think the distinction is more between approaches to software that are based on theory and approaches that are largely ad hoc. RDBMS is an example of a very successful early attempt based on theory, but there'll be many more. Most of contemporary OO falls in the ad hoc category, which will fade away, and no doubt my source of livelihood along with it :-) -- Daniel
|
|
0 |
|
Daniel
3/21/2005 11:53:05 PM
Costin Cozianu wrote: > >>>Nevermind, maybe another time, > >>>Alex > >>> > >> > >> > >>Whatever. Think ofn solving the challenge as a pre-condition to > > > > discuss > > > >>anything else, including the non-sense you're worried about. > > > > > > That's your position fair enough but that non-sense is exactly what I > > have to implement this week ;-| > > > > I need to implement a many to many relationship with users and groups > > where the definitive user list is a unix password file and groups are > > something else. My application is using Oracle with Java. > > > > I know some databases can tie tables to text files. I wonder if an > > Oracle (v9.2) table can be tied to a unix password file? > > > > I'm sure I'll solve the problem somehow but everything I can think of > > right now is ugly. I wonder how I should proceed? > > > > 1. Tie a table to a file? (that would be nice). > > 2. Write a service (like a daemon) that watches for changes in the > > password file and then syncs it with the DB User file? > > 3. Something else? > > > > My question amounts to I need a solution to this variation of the > > challenge. I don't care how many lines it takes as long as I can > > implement it in 2 days or less, either in Java or Oracle/SQL. > > > > I'm not sure if Costin is interested in helping but can he or anyone > > else help? > > > > Thanks, > > Alex. > > > > PS. comp.object is great for OO but for the future, is there another > > equivalent (ie good) news group for these types of questions > > comp.integration.nightares.maybe? > > > > Well, you haven't exactly specified the Unix system, but what I'd do is > consider the database the definitive source of data (because it simply > makes more sense), and have the Unix look up the users and groups > against Oracle. There's network equipment involved and it's all more complicated, so I simplified it. > You can do that certainly with Linux, including using LDAP module or > rolling your own. > Or yet another solution, if you really want to have the Unix system > behave independently, replace the suer management utilities on the > system with your own that both invoke the normal utility and send data > addition/modification/removals to Oracle. Thanks for your reply, it help's me know what kind of options I should dig into.
Rich MacDonald wrote: > alex99@medcentral.com.au wrote in news:1111429151.946988.158930 > @l41g2000cwc.googlegroups.com: > > > I need to implement a many to many relationship with users and groups > > where the definitive user list is a unix password file and groups are > > something else. My application is using Oracle with Java. > > > > I know some databases can tie tables to text files. I wonder if an > > Oracle (v9.2) table can be tied to a unix password file? > > > > I'm sure I'll solve the problem somehow but everything I can think of > > right now is ugly. I wonder how I should proceed? > > > > 1. Tie a table to a file? (that would be nice). > > 2. Write a service (like a daemon) that watches for changes in the > > password file and then syncs it with the DB User file? > > 3. Something else? > > I would probably go ahead and do (2) if I was in a hurry and was risk- > averse. > > You could try defining an Oracle table then using procedures to access it. > In your procedures you check the user file to see if the date has changed > and recalculate the table if needed. Hey that sounds good, I'll look into it. I will have a timestamp checker anyway, why not put all that in a procedure and do away with a separate service for it. Thanks, Alex.
alex99@medcentral.com.au wrote in news:1111460022.038963.217570 @o13g2000cwo.googlegroups.com: >> You could try defining an Oracle table then using procedures to > access it. >> In your procedures you check the user file to see if the date has > changed >> and recalculate the table if needed. > > Hey that sounds good, I'll look into it. I will have a timestamp > checker anyway, why not put all that in a procedure and do away with a > separate service for it. I should have mentioned in case you don't know, the "procedure" can be defined to override the select method. So queries still use "select ..." instead of callng some special procedure name.
|
|
0 |
|
Rich
3/22/2005 2:56:08 AM
(* didn't need, want, nor create all those features from scratch, of course that would be a big job. But the humble dbm file (available on unix since the 80s) can go a very long way. Perl has a *one* line function for using them. *) The problem is if/when you later need them, you may have to overhaul your application code. If you start out with a (simple) RDBMS, then you can later use a big-iron RDBMS without too much code overhaul. (* What would a database have gained? A headache, much more code....*) I would like to see an example of "much more code". I agree that existing relational products and languages could probably use a rework, but even with existing flaws, RDB's don't have to be a source of bloat if schemas are well-designed and one knows how to use them effectively. -T-
Costin Cozianu wrote:
> kurbylogic@hotmail.com wrote:
> > I'm kinda comming into the discussion a bit late, so I appologize
if I
> > reiterate points already made, but here goes.
> >
> > First I completely disagree with the idea that if we only had
enough
> > persistant ram we wouldn't want or need a relational store. Its
rather
> > about choosing the correct tool for the task at hand. If you have
a
> > nail use a hammer if you have a screw use a screw-driver. SQL is
> > designed to store and query large sets of structured data.
Howerver, it
> > isn't ideally suited for complex calculations or polymorphic
behavior.
> >
> >
>
> Ahem, you're right about complex calculation, not about "polymorphic
> behavior" -- there's no such thing.
>
> > So you've figured out how to prersist users/groups and their
> > relationships in a database without any OO code... well done what
do
> > you indend to do with it? I assume you are storing this data
because
> > you want to do something with it, correct? Perhaps this data is
used
> > to "authorize" a user for a specific task? perhaps they need they
need
> > to be a member of the "Lender" group before they are allowed to
approve
> > a loan application? Simple enough we can query if the user is IN
> > ('Lender') before allowing them do anything with Loan tables. But
lets
> > complicate things a bit shall we?
>
> Sure, let's. On the other hand, I shall not commit the imprudence of
> debating complex things until the simple ones have not been settled.
>
> > We decide we that simple groups are
> > not sufficient we need a bit more granularity so we want to assign
> > "rights" such as 'Approve Loan' to a user OR a group and allow
groups
> > to contain groups to make management of user rights easier.
> >
> > Now give me a simple query that can be used to determine if the
user
> > has the "Approve Loan" right granted directly to the user or any
groups
> > he is a member of and any groups those groups might be a member
of...
> > also remember that deny overrides any grant at any level).
> >
>
> Well, that is rather for the more sophisticated and well read DB
guru.
> However, technically it's not big deal after all.
>
> It boils down to
> SELECT right FROM TC_GROUPS tc JOIN GROUP_RIGHTS gr ON
(tc.in_group_id=
> gr.group_id)
> WHERE tc.group_id IN
> (SELECT group_id from users_groups ug WHERE ug.user_id= :user_id))
> AND right='Approve Loan';
>
> Where TC_GROUPS(group_id, in_group_id) is the transitive closure of
> group membership, the only relevant problem remaining being the
> maintenance of transitive closure. This is left as an exercise for
the
> reader.
>
> But before asking me to post a complete solution, could I see the OO
> counterpart ?
>
> > Lets add a bit more type dependant (polymorphic) functionality
shall
> > we... Our fictitious lender offers many different types of loans,
home
> > loans have greater risk so not all users that can approve a loan
can
> > approve all types of loans we have decided to create permissions
for
> > different types of loans and/or the value of the loan... home loans
> > require explicit approval by a user with the "Approve Home Loan"
right,
> > otherwise "Approve Loan" permission is good enough.
> >
> >
>
> That is rather trivial.
>
> > While your at it I (roleplaying customer) need an amoritization
> > schedule (the loan applicaiton has the principal loan amount,
annual
> > interest rate, loan duration and payment schedule (monthly,
quarterly,
> > weekly, etc)). If you can write an sproc or PL/SQL script for me
to do
> > that would be cool then I don't need to waste our presious network
> > resources to transmit the loan objects to the application tier.
> >
>
> Surely you don't mean to say that loan rates, amortizations, etc. are
> "complex calculations" ?
>
> >
> > I think your on to something with this SQL approach, we can give
all
> > our loan reps a Query Analyzer and if they want to create a loan
> > application they can just type exec sp_createLoan('... oh wait
customer
> > first exec sp_createCustomer('first.. wait I think last name goes
> > first... well nevermind guess we to create a gui of some sort
> > perhaps... what language did they use to create Query Analyzer (or
the
> > database engine for that matter)? I guess we need a high level
> > language for somethings, ah well.
>
> I guess you might be missing here that PL/SQL is a pretty high level
> language, and especially with regards to distinguishing positional
> parameters is better designed than java or C# or C++, because in
PL_SQL
> you can just say
> sp_xxx(
> ...
> first_name => 'Costin',
> last_name => 'Cozianu',
> ...
> );
>
> whereas in most OO languages you simply cannot name your parameters.
I
> guess this is an instance of ignorant irony that backfires.
>
>
> > The amoritization schedule you can
> > still do for me right?
>
> Right, but only after I'll have decided you're not an incompetent
troll.
> Given the quality of portions of your post, I am rather suspicious.
>
> > and you've already got me convinced the db is
> > the best place for this user/group thing, the additional complexity
> > isn't to much for you is it?
> >
> >
> > And about this thread saftey issue... I guess we don't need to
worry to
> > much about thread synchronization at the database level but I'm a
bit
> > concerned about multiple users working with the same data at the
same
> > time. I was reading something the other day about 'dirty data' and
> > 'phantom data' such as when a user inserts a row and then another
user
> > reads that row and then the user that inserted that row aborts his
> > transaction, are you familiar with this? I checked the docs and by
> > default SQL does not prevent phantom data! I guess they have
provided
> > an issolation level called serializable that prevents phantom data
but
> > the documentation says "use only when necessary." When do you
suppose
> > this is necessary? I don't want to generate a report and send it
off
> > for funding that that says we have approved a loan when that loan
> > approval hasn't even been commited yet! I'm torn about this
> > user/group/right scenario though, do you think we need to be
concerned
> > about dirty data and phantom reads?
> > Suppose we create this gui application and this application allows
the
> > administrator to change the user right assignments by checking a
few
> > boxes or something and then save his changes, I guess it probably
would
> > replace the existing options with the ones he is viewing right? so
if
> > he perhaps checks the deny on the 'approve home loan' box and
another
> > administrator was told to grant him permission to 'approve auto
loan',
> > last person to save wins right and he would still be authorized to
> > approve home loans? I guess we could just keep the transaction
open
> > with serializable issolation the entire time the administrator is
> > viewing those options so that the second admin isn't even allowed
to
> > view the data until the first admin finishes... but if we do that
we
> > may not be able to approve other users actions either and are
entire
> > system could come to a halt waiting on this one admin. I was
looking
> > into some alternatives, what do you think about optimistic
concurrency
> > control? this doesn't seem to be a 'native' database feature. Its
> > rather simplistic in theory though, when you read the data you also
> > include a version number and then when you do the update you
include
> > that same version number if it changed then you know its been
modified
> > by someone else, so the only lock that we need in this scenerio is
> > during the update.
>
>
> I guess you are more confused about the above scenario.
>
> If an admin takes away one user's right after that user has already
> performed an action it was previously authorized for, but no longer
> subsequently, then the action stays. The session that needs to be
> working under "serializable" is that of the user, not that of the
admin.
>
> Just because you've read about "optimistic concurrency" in some
> "popularization of science" books (I know how some OO circles felt in
> love with the idea) doesn't mean you understand the issues. And given
> how you framed the above problem I suspect a reading from a more
serious
> book (like "Transactional Information Systems")would help you think
> about these types of problems in a much sounder way.
>
>
> > What was it again in high-level languages you found
> > difficult (ArrayList.Synchronized method)?
> >
> >
>
> What was that you found easy ?
>
> Did you find it easy to deadlock, or did you find it easy to arrive
at
> inconsistent results inspite going through all kinds of locks ?
>
>
> >
> > Anyways, relational storage wont be going away anytime soon perhaps
> > never, the decomposition of the data makes it possible to construct
> > very effecient queries over large sets of data. Currently searching
> > object graphs is more difficult and less efficient then it could
be,
> > for example searching for all customers located in 'AZ' its not to
> > write a foreach loop, however it gets old and its somewhat
hard-coded
> > making arbitrary queries more difficult to implement efficiently, I
> > suspect someday technologies like XQuery might become a native part
of
> > the language allowing easy creation of arbitrary queries on object
> > graphs. Memory managers probably need some work in this area as
well,
> > ts not very efficient to query object graphs compared to a
database,
> > primarily because of the way that memory is allocated, objects are
> > allocated onto the heap in a somewhat arbitrary location based on
how
> > much data you want to allocate and what it has available, there is
no
> > gaurantee that objects of the same type will be located remotely
close
> > to each other in memory or in memory at all (paged to disk), so a
> > statment like foreach customer in getcustomers() { if
> > customer.address.state = "AZ" list.add(customer); } could result in
> > lots of memory paging. The database manages the memory much
> > differently loading records of the same type close together in
"pages"
> > with fixed record lengths allowing quick navigation from one
address
> > record to the next address record. I suspect someday heap
allocation
> > for objects might become more optimized for querying done more like
a
> > database where objects of the same type will be allocated in the
same
> > location (inheritance I'm sure complicates this but perhaps some
form
> > of replication of base class properties as one might denormalize a
> > database could work but I'm not an expert on that kinda thing
anyway).
> > Databases however are learning to work better with (not to
eliminate)
> > OO apps, in a way that is more object graph friendly, SQL 2005 will
> > allow multiple active result sets or xml resultsets provide ways
make
> > it easier to read an object and its children in one step from
multiple
> > tables simultaniously rather then needing to read all customer data
> > then go back to each customer previously read to add the address
> > record. Asynchronous notification makes it possible to be informed
> > when things change rather then needing to repeadedly read the
database
> > to ensure you are most up to date. SQL 2005 has some useful
features
> > to help bridge the gap between OO and relational, each tool has a
> > purpose neither trying to elimiate the other just the gap, the goal
is
> > rather to get "seamless integration" so they play nice giving the
> > developer the most productive tool for the current task without
having
> > to pick one or the other and/or become a bridge builder.
> >
> > - Kurt
> >
>
> Nice deluge of irrelevant 2c that I cannot make any sense of. I'd
rather
> recommend to you and all contributors to this thread to stay strictly
> technical and within your areas of competence, refraining from
> unwarranted speculations.
>
> For example it would have helped if rather than being unsubtly ironic
> about stuff you think databases cannot handle, you would have tried a
> more prudent tone along the lines "In my experience, I found
difficult
> addressing this kind of issues". Because it may turn out that irony
> backfires and bites you somewhere unpleasant .
>
> And again, before complicating this challenge to no end, I'd rather
see
> the response to the simple challenge, and it would also help if
> proponents of new challenges would have already worked out one
solution
> using their technology/approach of their choice so that they can post
it
> and/or estimate the complexity, rather than playing it for a sport.
The point I wanted to make is that one should choose the correct tool
for the correct task... I don't store users and groups and/or maintain
relationships just to have users and groups I do so only because I want
to do something with them, such as authorize an action, in OO the
complexity of mapping database tables to objects is useful only if the
object has behavior, such as Loan.Approve() that involves more then
just updating a field. If all you want to do is create a list of users
and groups and maintain some relationship between them then an OO
solution has little value and given the choice between a database or OO
solution to the problem I too would use the database, nearly every
application I write anymore involves a database as part of the
solution, but a database alone cannot provide a complete end-to-end
solution.
The amoritization schedule is a recursive operation and why I presented
it not because it is inherantly "complex" the resulting code would be a
more procedural rather then set oriented operation, so why not use a
procedural language.
The database might be "thread-safe" but thread-saftey does not prevent
data in all cases from becoming inconsistant. I phrased my response
roleplaying a somewhat ignorant customer that has concerns... prompting
you the expert to explain how "thread-saftey" ensures options cannot be
overwritten as may sometimes happen if data is copied (perhaps to a
temp table) and then updates are made based on stale data, or how
thread-saftey prevents non-commited records from appearing in another
users query (such as reporting a new loanapproval record that has not
yet been commited). It is not thread-saftey alone that ensures data
concistancy, it must be coupled with issolation, issolation is the
easiest and probably most common OO approach to concurrency issues in
object solutions, instead of locking making deadlock detection a
useless feature. User u = new User(); u.SetName(name); is a completely
thread safe operation because that user object is completely invisible
to other threads. Replacing one object instance with another object
instance is completely atomic operation, this doesn't have to be a
simple object it can be a composite object with as much or as little
state as you need to ensure that an all or nothing set operation
results in a consistant system state without requireing any locks at
all. This is not true with the database where inserts that have not
yet commited can be seen by other or users, data possibly used to
perform an operation such as transferring reducing the total funds
availabe for lending based on data that has possibly been rolled back
leaving the system in a inconsistant state.
So in response to your initial challenge, the following addresses ONLY
your solution as you insist and is thread safe (policy class does not
need to be thread safe because a thread can only get an instance of it
via new Policy() or from the SecurityManager which returns a new
instance with a copy of the current state therefore it is issolated
from other threads and does not require any locking)
public class SecurityManager
{
static Policy policy = new Policy(); // initially empty
public static Policy GetPolicy()
{ return policy.Clone(); }
public static SetPolicy(Policy p)
{ policy = value.Clone(); } // atomic operation, no lock required
public static bool IsUserInGroup(string user, string group)
{
return policy.IsUserInGroup(user, group);
}
}
public class Policy
{
ArrayList users = new ArrayList();
ArrayList groups = new ArrayList();
ArrayList usergroups = new ArrayList();
public void AddUser(string user) { users.Add(user); }
public void AddGroup(string group) { groups.Add(group); }
public void RemoveUser(string user) { users.Remove(user); }
public void RemoveGroup(string group) { groups.Remove(group); }
public void AssignUserToGroup(string user, string group)
{
if(users.Contains(user) && groups.Contains(group))
usergroups.Add(new UserGroupAssignment(user, group));
}
public void RemoveUserFromGroup(string user, string group)
{
usergroups.Remove(new UserGroupAssignment(user, group));
}
public bool IsUserInGroup(string user, string group)
{
return usergroups.Contains(new UserGroupAssignment(user, group));
}
public Policy Clone()
{
Policy p = new Policy();
p.users = (ArrayList)users.Clone();
p.groups = (ArrayList)groups.Clone();
p.usergroups = (ArrayList)usergroups.Clone();
return p;
}
struct UserGroupAssignment
{
string user;
string group;
public UserGroupAssignment(string user, string group)
{
this.user = user;
this.group = group;
}
}
}
You refuse to add any more complexity to this task, yet bring up yet
bring up "deadlock detection" which isn't even remotely necessary in a
solution that requires no locks. You claim the OO solution requies
more code for THIS - ONLY THIS problem compared to a create table
creation script, come-on really?
It is only slightly longer than your table creation script, but you did
not include any procedure creation scripts therefore I assume that you
must expect the client to query the user/group tables directly...
If/When we decied to add groups into groups all changes are issolated
to the policy class, you would have to update all of your "only one
statement..." in dozens if not hundreds of locations, I have only one
location to make changes to, the code used by my client remains the
same. You could and probably would create an sproc or whatever but by
the time you have written the Create Procedure ... As ... for each of
those "in one statement...". If you include the SQL to create
procedures (especially if you add the standard if exist drop statments
to your table and procedure creation scripts) than your code would be
just as long as mine! I suppose I could eliminate the methods on my
class and expose the private members to reduce the lines in my code as
you have to some extent done, we've learned the lessons about exposing
implementation details, so if you want to compare apples to apples (to
the extent possible) add the code for the procedures, how many lines
have we now? Is it more then 35 (my total solution not including the
{}s).
Relational databases aren't going away, but not because they are less
complex. I guess you can call SQL is a "high-level" language, its
purpose is however different, it is a set oriented language it works
well with sets of structured data, OO languages provide polymorphic
behavior which you deny even exists, polymorphic behavior is a large
part of why OO languages were created in the first place and why they
have become "mainstream" languages. So if you are going to complain an
many-many relationship in OO is *too complex* (which of the 35 lines
was complex?) then abandon OO write all your business logic in in SQL,
write a real application that does something with those users and
groups you have created and then try and maintain it for the next 5 or
so years, enhance and extend it for new requirements so it can last
another 5 or so years. Then maybe you too will be asking why can't I
just save the current state of my system into the database without
having to to shread an order object it into line items, billing and
shipping address records, why can't I say load the current state of the
system without having to reconstruct object graphs from dozens of
seperate tables. If persistance was the only useful service provided
by a relational database then I suppose more persistant memory is all
one would need. But obviously you are not interested in the
big-picture just the overwelming complexity in the 35 lines of code to
implement a many-many user group relationship. So perhaps you should
"stay strictly technical and within your areas of competence,
refraining from unwarranted speculations" regarding the limitations or
usefulness of object databases and/or object relational mappers.
Someone who does not see value in an OO language either because he
refuses to or cannot face the inevitable complexity of any real
application, or because the "complexity" of a many-many relationship is
too much to handle, than I couldn't possible expect him to see any
value in an object database either. You clearly have no appreciation
for its need. I'm not really sure what the purpose of your thread is,
your OO solution has been given not only by me and requires only a few
more (if any in practice) lines of code and isn't remotely complex. I
would be interested in an discussion about the value of object database
solutions and limitations of object databases, but as you openly
admitted you saw no relevance and have no understanding of the progress
or issues involved. Unless you have a more substantial argument
against them, I don't see any value in your opinion on this subject.
- Kurt
On 22 Mar 2005 02:56:16 -0800, kurbylogic@hotmail.com wrote: > The database might be "thread-safe" but thread-saftey does not prevent > data in all cases from becoming inconsistant. = thread-unsafe > You refuse to add any more complexity to this task, yet bring up yet > bring up "deadlock detection" which isn't even remotely necessary in a > solution that requires no locks. .... wisely avoiding to mention either race condition elimination or the issue of meeting deadlines. I believe you are wasting your time. See my attempt at 11 March 2005... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
"Daniel Parker" <danielaparker@hotmail.com> wrote in message news:<1111429065.834515.138200@o13g2000cwo.googlegroups.com>... > "How can OO be worse than a RDBMS when it's model is powerful enought > to build one?" -- Jeff Brooks > > are literally incomprehensible, not just to relational people, but to > anyone capable of thought. What does "worse" mean? What does > "powerful" mean? And what does "model" mean? > Such statements are meaningless. Uttlerly. > Alfredo also sometimes makes statements that seem to suggest that a > great deal of what we commonly regard as application code properly > belongs in the database. These statements are not typical of > commentary by relational people. The most Date will say is "I'd just > like to make it clear that my criticisms of objects and 'object > orientation' have always been aimed at their usefulness or otherwise in > a database context and not necessarily in any other." And Pascal, "My > criticism of OO is purely as a database management technology. I have > little to say about it as a programming approach, because that's > neither my interest, nor my expertise." I disagree because the parts that people incorrectly reagard to application code are precisely the ones about database management. > > (2) if an RDBMS has to be implemented in a non-relational language, > then > > is the relational model as universally powerful as it claims to be? > God help us, words without meaning, whatever happened to the language? > What claims? Powerful, in what sense? What would an algeraic model of > data sensibly aspire to here? And an RDBMS could be implemented in a relational language. Regards
"frebe" <fredrik_bertilsson@passagen.se> wrote in message news:<1111344481.561855.259340@z14g2000cwz.googlegroups.com>... > I have recently converted a large enterprise application originally > written for Informix, to support Oracle and SQL Server as well. 99,99% > of the SQL statements are identical for all dialects. So to have three different versions for the remaining 0,01% would not be very painful. Regards
"Daniel Parker" <danielaparker@spam?nothanks.windupbird.com> wrote in message news:<znh%d.359$nK.97578@news20.bellglobal.com>... > He knows about UML, being an author of books with UML in the title, and all > that. But the concept of "model" seems to be a little different in UML then > in applied mathematics, statistics, physics, or even economics, and in > particular in relational theory. "Model" is one of the most heavily overloaded words. It may mean many things that have little to do among them. An UML model has very little to do with the Relational Model nor with Claudia Schiffer. Regards
alex99@medcentral.com.au wrote in message news:<1111143210.110259.225630@g14g2000cwa.googlegroups.com>... > Alfredo Novoa wrote: > > On 14 Mar 2005 03:56:46 -0800, alex99@medcentral.com.au wrote: > > > > >I'm sorry I don't have time to pursue your challenge but I must say > I'm > > >a fan of what works. > > > > I supose that it is due to the big amount of work needed to solve the > > challenge without a DBMS. > > No, it's actually because my current employer (Cisco Systems) seems to > prefer me to work on their project rather than on any challenges > presented on the web ;-) But using a relational DBMS you could solve the challenge in a fraction of the time you spent with this post. > There are many other ways to deal with information and all very > powerfully:- HTML/gif/jpg, XML, dbm files, serialization, regular > files, corba, a multitude of web services etc etc ... All poor approaches. > Querying is only > one piece of the jigsaw puzzle. Indeed. Queries are a little part of what a DBMS offers. > Frankly I would prefer a large enough nonvolitile memory bank with > sufficient network facilities with not disk and no database. DBMS, not database. And I would prefer a large enough memory bank (volatility is not important) to use an RDBMS. Regards
Following script for a small experimental db (XDb3) models users and
groups. Sample queries at end.
// Create groups.
(CREATE type inst *group)
(CREATE group inst *admin)
(CREATE group inst *super)
(CREATE group inst *worker)
(CREATE group inst *guest)
// Create users.
(CREATE type inst *user)
(CREATE user inst *john
& it group admin)
(CREATE user inst *mary
& it group admin
& it group super
& it group worker)
(CREATE user inst *bob
& it group worker
& it group guest)
// Find mary's groups.
// Finds admin, super, worker.
(SELECT mary group *)
// Find persons belong to worker group.
// Finds mary and bob.
(SELECT * group worker)
// Find relationship between john and admin.
// Finds group.
(SELECT john * admin)
neo55592kurbylogic@hotmail.com wrote:
> Costin Cozianu wrote:
>
>>kurbylogic@hotmail.com wrote:
>>
>>>I'm kinda comming into the discussion a bit late, so I appologize
>
> if I
>
>>>reiterate points already made, but here goes.
>>>
>>>First I completely disagree with the idea that if we only had
>
> enough
>
>>>persistant ram we wouldn't want or need a relational store. Its
>
> rather
>
>>>about choosing the correct tool for the task at hand. If you have
>
> a
>
>>>nail use a hammer if you have a screw use a screw-driver. SQL is
>>>designed to store and query large sets of structured data.
>
> Howerver, it
>
>>>isn't ideally suited for complex calculations or polymorphic
>
> behavior.
>
>>>
>>Ahem, you're right about complex calculation, not about "polymorphic
>>behavior" -- there's no such thing.
>>
>>
>>>So you've figured out how to prersist users/groups and their
>>>relationships in a database without any OO code... well done what
>
> do
>
>>>you indend to do with it? I assume you are storing this data
>
> because
>
>>>you want to do something with it, correct? Perhaps this data is
>
> used
>
>>>to "authorize" a user for a specific task? perhaps they need they
>
> need
>
>>>to be a member of the "Lender" group before they are allowed to
>
> approve
>
>>>a loan application? Simple enough we can query if the user is IN
>>>('Lender') before allowing them do anything with Loan tables. But
>
> lets
>
>>>complicate things a bit shall we?
>>
>>Sure, let's. On the other hand, I shall not commit the imprudence of
>>debating complex things until the simple ones have not been settled.
>>
>>
>>> We decide we that simple groups are
>>>not sufficient we need a bit more granularity so we want to assign
>>>"rights" such as 'Approve Loan' to a user OR a group and allow
>
> groups
>
>>>to contain groups to make management of user rights easier.
>>>
>>>Now give me a simple query that can be used to determine if the
>
> user
>
>>>has the "Approve Loan" right granted directly to the user or any
>
> groups
>
>>>he is a member of and any groups those groups might be a member
>
> of...
>
>>>also remember that deny overrides any grant at any level).
>>>
>>
>>Well, that is rather for the more sophisticated and well read DB
>
> guru.
>
>>However, technically it's not big deal after all.
>>
>>It boils down to
>> SELECT right FROM TC_GROUPS tc JOIN GROUP_RIGHTS gr ON
>
> (tc.in_group_id=
>
>>gr.group_id)
>> WHERE tc.group_id IN
>> (SELECT group_id from users_groups ug WHERE ug.user_id= :user_id))
>> AND right='Approve Loan';
>>
>>Where TC_GROUPS(group_id, in_group_id) is the transitive closure of
>>group membership, the only relevant problem remaining being the
>>maintenance of transitive closure. This is left as an exercise for
>
> the
>
>>reader.
>>
>>But before asking me to post a complete solution, could I see the OO
>>counterpart ?
>>
>>
>>>Lets add a bit more type dependant (polymorphic) functionality
>
> shall
>
>>>we... Our fictitious lender offers many different types of loans,
>
> home
>
>>>loans have greater risk so not all users that can approve a loan
>
> can
>
>>>approve all types of loans we have decided to create permissions
>
> for
>
>>>different types of loans and/or the value of the loan... home loans
>>>require explicit approval by a user with the "Approve Home Loan"
>
> right,
>
>>>otherwise "Approve Loan" permission is good enough.
>>>
>>>
>>
>>That is rather trivial.
>>
>>
>>>While your at it I (roleplaying customer) need an amoritization
>>>schedule (the loan applicaiton has the principal loan amount,
>
> annual
>
>>>interest rate, loan duration and payment schedule (monthly,
>
> quarterly,
>
>>>weekly, etc)). If you can write an sproc or PL/SQL script for me
>
> to do
>
>>>that would be cool then I don't need to waste our presious network
>>>resources to transmit the loan objects to the application tier.
>>>
>>
>>Surely you don't mean to say that loan rates, amortizations, etc. are
>
>
>>"complex calculations" ?
>>
>>
>>>I think your on to something with this SQL approach, we can give
>
> all
>
>>>our loan reps a Query Analyzer and if they want to create a loan
>>>application they can just type exec sp_createLoan('... oh wait
>
> customer
>
>>>first exec sp_createCustomer('first.. wait I think last name goes
>>>first... well nevermind guess we to create a gui of some sort
>>>perhaps... what language did they use to create Query Analyzer (or
>
> the
>
>>>database engine for that matter)? I guess we need a high level
>>>language for somethings, ah well.
>>
>>I guess you might be missing here that PL/SQL is a pretty high level
>>language, and especially with regards to distinguishing positional
>>parameters is better designed than java or C# or C++, because in
>
> PL_SQL
>
>>you can just say
>> sp_xxx(
>>...
>> first_name => 'Costin',
>> last_name => 'Cozianu',
>>...
>>);
>>
>>whereas in most OO languages you simply cannot name your parameters.
>
> I
>
>>guess this is an instance of ignorant irony that backfires.
>>
>>
>>
>>>The amoritization schedule you can
>>>still do for me right?
>>
>>Right, but only after I'll have decided you're not an incompetent
>
> troll.
>
>>Given the quality of portions of your post, I am rather suspicious.
>>
>>
>>>and you've already got me convinced the db is
>>>the best place for this user/group thing, the additional complexity
>>>isn't to much for you is it?
>>>
>>>
>>>And about this thread saftey issue... I guess we don't need to
>
> worry to
>
>>>much about thread synchronization at the database level but I'm a
>
> bit
>
>>>concerned about multiple users working with the same data at the
>
> same
>
>>>time. I was reading something the other day about 'dirty data' and
>>>'phantom data' such as when a user inserts a row and then another
>
> user
>
>>>reads that row and then the user that inserted that row aborts his
>>>transaction, are you familiar with this? I checked the docs and by
>>>default SQL does not prevent phantom data! I guess they have
>
> provided
>
>>>an issolation level called serializable that prevents phantom data
>
> but
>
>>>the documentation says "use only when necessary." When do you
>
> suppose
>
>>>this is necessary? I don't want to generate a report and send it
>
> off
>
>>>for funding that that says we have approved a loan when that loan
>>>approval hasn't even been commited yet! I'm torn about this
>>>user/group/right scenario though, do you think we need to be
>
> concerned
>
>>>about dirty data and phantom reads?
>>>Suppose we create this gui application and this application allows
>
> the
>
>>>administrator to change the user right assignments by checking a
>
> few
>
>>>boxes or something and then save his changes, I guess it probably
>
> would
>
>>>replace the existing options with the ones he is viewing right? so
>
> if
>
>>>he perhaps checks the deny on the 'approve home loan' box and
>
> another
>
>>>administrator was told to grant him permission to 'approve auto
>
> loan',
>
>>>last person to save wins right and he would still be authorized to
>>>approve home loans? I guess we could just keep the transaction
>
> open
>
>>>with serializable issolation the entire time the administrator is
>>>viewing those options so that the second admin isn't even allowed
>
> to
>
>>>view the data until the first admin finishes... but if we do that
>
> we
>
>>>may not be able to approve other users actions either and are
>
> entire
>
>>>system could come to a halt waiting on this one admin. I was
>
> looking
>
>>>into some alternatives, what do you think about optimistic
>
> concurrency
>
>>>control? this doesn't seem to be a 'native' database feature. Its
>>>rather simplistic in theory though, when you read the data you also
>>>include a version number and then when you do the update you
>
> include
>
>>>that same version number if it changed then you know its been
>
> modified
>
>>>by someone else, so the only lock that we need in this scenerio is
>>>during the update.
>>
>>
>>I guess you are more confused about the above scenario.
>>
>>If an admin takes away one user's right after that user has already
>>performed an action it was previously authorized for, but no longer
>>subsequently, then the action stays. The session that needs to be
>>working under "serializable" is that of the user, not that of the
>
> admin.
>
>>Just because you've read about "optimistic concurrency" in some
>>"popularization of science" books (I know how some OO circles felt in
>
>
>>love with the idea) doesn't mean you understand the issues. And given
>
>
>>how you framed the above problem I suspect a reading from a more
>
> serious
>
>>book (like "Transactional Information Systems")would help you think
>>about these types of problems in a much sounder way.
>>
>>
>>
>>>What was it again in high-level languages you found
>>>difficult (ArrayList.Synchronized method)?
>>>
>>>
>>
>>What was that you found easy ?
>>
>>Did you find it easy to deadlock, or did you find it easy to arrive
>
> at
>
>>inconsistent results inspite going through all kinds of locks ?
>>
>>
>>
>>>Anyways, relational storage wont be going away anytime soon perhaps
>>>never, the decomposition of the data makes it possible to construct
>>>very effecient queries over large sets of data. Currently searching
>>>object graphs is more difficult and less efficient then it could
>
> be,
>
>>>for example searching for all customers located in 'AZ' its not to
>>>write a foreach loop, however it gets old and its somewhat
>
> hard-coded
>
>>>making arbitrary queries more difficult to implement efficiently, I
>>>suspect someday technologies like XQuery might become a native part
>
> of
>
>>>the language allowing easy creation of arbitrary queries on object
>>>graphs. Memory managers probably need some work in this area as
>
> well,
>
>>>ts not very efficient to query object graphs compared to a
>
> database,
>
>>>primarily because of the way that memory is allocated, objects are
>>>allocated onto the heap in a somewhat arbitrary location based on
>
> how
>
>>>much data you want to allocate and what it has available, there is
>
> no
>
>>>gaurantee that objects of the same type will be located remotely
>
> close
>
>>>to each other in memory or in memory at all (paged to disk), so a
>>>statment like foreach customer in getcustomers() { if
>>>customer.address.state = "AZ" list.add(customer); } could result in
>>>lots of memory paging. The database manages the memory much
>>>differently loading records of the same type close together in
>
> "pages"
>
>>>with fixed record lengths allowing quick navigation from one
>
> address
>
>>>record to the next address record. I suspect someday heap
>
> allocation
>
>>>for objects might become more optimized for querying done more like
>
> a
>
>>>database where objects of the same type will be allocated in the
>
> same
>
>>>location (inheritance I'm sure complicates this but perhaps some
>
> form
>
>>>of replication of base class properties as one might denormalize a
>>>database could work but I'm not an expert on that kinda thing
>
> anyway).
>
>>> Databases however are learning to work better with (not to
>
> eliminate)
>
>>>OO apps, in a way that is more object graph friendly, SQL 2005 will
>>>allow multiple active result sets or xml resultsets provide ways
>
> make
>
>>>it easier to read an object and its children in one step from
>
> multiple
>
>>>tables simultaniously rather then needing to read all customer data
>>>then go back to each customer previously read to add the address
>>>record. Asynchronous notification makes it possible to be informed
>>>when things change rather then needing to repeadedly read the
>
> database
>
>>>to ensure you are most up to date. SQL 2005 has some useful
>
> features
>
>>>to help bridge the gap between OO and relational, each tool has a
>>>purpose neither trying to elimiate the other just the gap, the goal
>
> is
>
>>>rather to get "seamless integration" so they play nice giving the
>>>developer the most productive tool for the current task without
>
> having
>
>>>to pick one or the other and/or become a bridge builder.
>>>
>>>- Kurt
>>>
>>
>>Nice deluge of irrelevant 2c that I cannot make any sense of. I'd
>
> rather
>
>>recommend to you and all contributors to this thread to stay strictly
>
>
>>technical and within your areas of competence, refraining from
>>unwarranted speculations.
>>
>>For example it would have helped if rather than being unsubtly ironic
>
>
>>about stuff you think databases cannot handle, you would have tried a
>
>
>>more prudent tone along the lines "In my experience, I found
>
> difficult
>
>>addressing this kind of issues". Because it may turn out that irony
>>backfires and bites you somewhere unpleasant .
>>
>>And again, before complicating this challenge to no end, I'd rather
>
> see
>
>>the response to the simple challenge, and it would also help if
>>proponents of new challenges would have already worked out one
>
> solution
>
>>using their technology/approach of their choice so that they can post
>
> it
>
>>and/or estimate the complexity, rather than playing it for a sport.
>
>
> The point I wanted to make is that one should choose the correct tool
> for the correct task... I don't store users and groups and/or maintain
> relationships just to have users and groups I do so only because I want
> to do something with them, such as authorize an action, in OO the
> complexity of mapping database tables to objects is useful only if the
> object has behavior, such as Loan.Approve() that involves more then
> just updating a field. If all you want to do is create a list of users
> and groups and maintain some relationship between them then an OO
> solution has little value and given the choice between a database or OO
> solution to the problem I too would use the database, nearly every
> application I write anymore involves a database as part of the
> solution, but a database alone cannot provide a complete end-to-end
> solution.
> The amoritization schedule is a recursive operation and why I presented
> it not because it is inherantly "complex" the resulting code would be a
> more procedural rather then set oriented operation, so why not use a
> procedural language.
> The database might be "thread-safe" but thread-saftey does not prevent
> data in all cases from becoming inconsistant. I phrased my response
> roleplaying a somewhat ignorant customer that has concerns... prompting
> you the expert to explain how "thread-saftey" ensures options cannot be
> overwritten as may sometimes happen if data is copied (perhaps to a
> temp table) and then updates are made based on stale data, or how
> thread-saftey prevents non-commited records from appearing in another
> users query (such as reporting a new loanapproval record that has not
> yet been commited). It is not thread-saftey alone that ensures data
> concistancy, it must be coupled with issolation, issolation is the
> easiest and probably most common OO approach to concurrency issues in
> object solutions, instead of locking making deadlock detection a
> useless feature. User u = new User(); u.SetName(name); is a completely
> thread safe operation because that user object is completely invisible
> to other threads. Replacing one object instance with another object
> instance is completely atomic operation, this doesn't have to be a
> simple object it can be a composite object with as much or as little
> state as you need to ensure that an all or nothing set operation
> results in a consistant system state without requireing any locks at
> all. This is not true with the database where inserts that have not
> yet commited can be seen by other or users, data possibly used to
> perform an operation such as transferring reducing the total funds
> availabe for lending based on data that has possibly been rolled back
> leaving the system in a inconsistant state.
>
> So in response to your initial challenge, the following addresses ONLY
> your solution as you insist and is thread safe (policy class does not
> need to be thread safe because a thread can only get an instance of it
> via new Policy() or from the SecurityManager which returns a new
> instance with a copy of the current state therefore it is issolated
> from other threads and does not require any locking)
>
> public class SecurityManager
> {
> static Policy policy = new Policy(); // initially empty
> public static Policy GetPolicy()
> { return policy.Clone(); }
> public static SetPolicy(Policy p)
> { policy = value.Clone(); } // atomic operation, no lock required
>
> public static bool IsUserInGroup(string user, string group)
> {
> return policy.IsUserInGroup(user, group);
> }
> }
> public class Policy
> {
> ArrayList users = new ArrayList();
> ArrayList groups = new ArrayList();
> ArrayList usergroups = new ArrayList();
>
> public void AddUser(string user) { users.Add(user); }
> public void AddGroup(string group) { groups.Add(group); }
> public void RemoveUser(string user) { users.Remove(user); }
> public void RemoveGroup(string group) { groups.Remove(group); }
>
> public void AssignUserToGroup(string user, string group)
> {
> if(users.Contains(user) && groups.Contains(group))
> usergroups.Add(new UserGroupAssignment(user, group));
> }
> public void RemoveUserFromGroup(string user, string group)
> {
> usergroups.Remove(new UserGroupAssignment(user, group));
> }
> public bool IsUserInGroup(string user, string group)
> {
> return usergroups.Contains(new UserGroupAssignment(user, group));
> }
> public Policy Clone()
> {
> Policy p = new Policy();
> p.users = (ArrayList)users.Clone();
> p.groups = (ArrayList)groups.Clone();
> p.usergroups = (ArrayList)usergroups.Clone();
> return p;
> }
> struct UserGroupAssignment
> {
> string user;
> string group;
> public UserGroupAssignment(string user, string group)
> {
> this.user = user;
> this.group = group;
> }
> }
> }
>
> You refuse to add any more complexity to this task, yet bring up yet
> bring up "deadlock detection" which isn't even remotely necessary in a
> solution that requires no locks. You claim the OO solution requies
> more code for THIS - ONLY THIS problem compared to a create table
> creation script, come-on really?
> It is only slightly longer than your table creation script, but you did
> not include any procedure creation scripts therefore I assume that you
> must expect the client to query the user/group tables directly...
> If/When we decied to add groups into groups all changes are issolated
> to the policy class, you would have to update all of your "only one
> statement..." in dozens if not hundreds of locations, I have only one
> location to make changes to, the code used by my client remains the
> same. You could and probably would create an sproc or whatever but by
> the time you have written the Create Procedure ... As ... for each of
> those "in one statement...". If you include the SQL to create
> procedures (especially if you add the standard if exist drop statments
> to your table and procedure creation scripts) than your code would be
> just as long as mine! I suppose I could eliminate the methods on my
> class and expose the private members to reduce the lines in my code as
> you have to some extent done, we've learned the lessons about exposing
> implementation details, so if you want to compare apples to apples (to
> the extent possible) add the code for the procedures, how many lines
> have we now? Is it more then 35 (my total solution not including the
> {}s).
>
> Relational databases aren't going away, but not because they are less
> complex. I guess you can call SQL is a "high-level" language, its
> purpose is however different, it is a set oriented language it works
> well with sets of structured data, OO languages provide polymorphic
> behavior which you deny even exists, polymorphic behavior is a large
> part of why OO languages were created in the first place and why they
> have become "mainstream" languages. So if you are going to complain an
> many-many relationship in OO is *too complex* (which of the 35 lines
> was complex?) then abandon OO write all your business logic in in SQL,
> write a real application that does something with those users and
> groups you have created and then try and maintain it for the next 5 or
> so years, enhance and extend it for new requirements so it can last
> another 5 or so years. Then maybe you too will be asking why can't I
> just save the current state of my system into the database without
> having to to shread an order object it into line items, billing and
> shipping address records, why can't I say load the current state of the
> system without having to reconstruct object graphs from dozens of
> seperate tables. If persistance was the only useful service provided
> by a relational database then I suppose more persistant memory is all
> one would need. But obviously you are not interested in the
> big-picture just the overwelming complexity in the 35 lines of code to
> implement a many-many user group relationship. So perhaps you should
> "stay strictly technical and within your areas of competence,
> refraining from unwarranted speculations" regarding the limitations or
> usefulness of object databases and/or object relational mappers.
> Someone who does not see value in an OO language either because he
> refuses to or cannot face the inevitable complexity of any real
> application, or because the "complexity" of a many-many relationship is
> too much to handle, than I couldn't possible expect him to see any
> value in an object database either. You clearly have no appreciation
> for its need. I'm not really sure what the purpose of your thread is,
> your OO solution has been given not only by me and requires only a few
> more (if any in practice) lines of code and isn't remotely complex. I
> would be interested in an discussion about the value of object database
> solutions and limitations of object databases, but as you openly
> admitted you saw no relevance and have no understanding of the progress
> or issues involved. Unless you have a more substantial argument
> against them, I don't see any value in your opinion on this subject.
>
> - Kurt
>
First fix your broken code and only after that take a grand standing
with such pompous statements.
Costin Cozianu <c_cozianu@hotmail.com> wrote in message news:<3a8dmdF68v3ioU1@individual.net>... > > designed to store and query large sets of structured data. Howerver, it > > isn't ideally suited for complex calculations or polymorphic behavior. > > Ahem, you're right about complex calculation, Do you mean that a query can not require a complex calculation? > not about "polymorphic > behavior" -- there's no such thing. Indeed, that's meaningless pap. Regards
Rich MacDonald wrote: > alex99@medcentral.com.au wrote in news:1111460022.038963.217570 > @o13g2000cwo.googlegroups.com: > > >> You could try defining an Oracle table then using procedures to > > access it. > >> In your procedures you check the user file to see if the date has > > changed > >> and recalculate the table if needed. > > > > Hey that sounds good, I'll look into it. I will have a timestamp > > checker anyway, why not put all that in a procedure and do away with a > > separate service for it. > > I should have mentioned in case you don't know, the "procedure" can be > defined to override the select method. So queries still use "select ...." > instead of callng some special procedure name. Wow that sounds even better. And no I didn't know you could override the select method, where do I begin? Thanks again.
alfredo_novoa@hotmail.com (Alfredo Novoa) wrote in news:25870418.0503220530.28512a03@posting.google.com: > "frebe" <fredrik_bertilsson@passagen.se> wrote in message > news:<1111344481.561855.259340@z14g2000cwz.googlegroups.com>... > >> I have recently converted a large enterprise application originally >> written for Informix, to support Oracle and SQL Server as well. >> 99,99% of the SQL statements are identical for all dialects. > > So to have three different versions for the remaining 0,01% would not > be very painful. Duh. YMV. My experience is quite the opposite. I use HQSL (or some other simple RAM standin) for my test environment and something else for production. I have to create, update and destroy the database many times during my tests. For even the most simple schemas, there is no such thing as SQL compatibility. Try generating the database creation statements using a program to create the SQL string. You'll be surprised.
|
|
0 |
|
Rich
3/23/2005 12:39:15 AM
alex99@medcentral.com.au wrote in news:1111534774.100237.124250 @z14g2000cwz.googlegroups.com: > And no I didn't know you could override the select method, where do I > begin? None of that stuff is handy to me right now and I can't remember off the top of my head...except that its really trivial once you see the code. I was hoping some of our experienced SQLers would chime in (since us OOers are so clueless, really :-). I could probably get it for you by tomorrow night if need be.
|
|
0 |
|
Rich
3/23/2005 12:43:17 AM
Dmitry A. Kazakov wrote: > On 22 Mar 2005 02:56:16 -0800, kurbylogic@hotmail.com wrote: > > >>The database might be "thread-safe" but thread-saftey does not prevent >>data in all cases from becoming inconsistant. > > > = thread-unsafe > > >>You refuse to add any more complexity to this task, yet bring up yet >>bring up "deadlock detection" which isn't even remotely necessary in a >>solution that requires no locks. > > > ... wisely avoiding to mention either race condition elimination or the > issue of meeting deadlines. > > I believe you are wasting your time. See my attempt at 11 March 2005... > Actually FYI, you're repplying approvingly to something that was posted from ignorance. Database has enough mechanisms to prevent data from becoming incosistent, unlike the concurrency model in most programming languages. That's why it is easy to meet deadlines when concurrent transactions are handled by databases: that unlike OO code that has *no obvious concurrency related bugs* (such as is the case of the code posted by kurby, and as would probably be the case with code posted by you along the lines you alluded to on 11 March 2005), SQL databases provide the mechanisms (namely transaction and isolation levels) that makes it easy to write code with *obviously no concurrency related bugs* Now which of the two properties is preferrable is left as an exercise for the reader.
> First fix your broken code and only after that take a grand standing
> with such pompous statements.
Ah yes, I suppose I intentionally omitted the *complex* part right? it was
nearly 4 am when I coded that, thankfully because there is some
encapsulation I can fix my solution without changing the client.
Add the following before groups.Remove(group)
foreach(user in users)
if (UserIsInGroup(user, group)) RemoveUserFromGroup(user, group);
And likewise for RemoveUser but looping over groups instead, clearly not
complex, I think you can handle it.
I suppose now after pointing out how you only need 35 lines of code you are
going to make a big deal over these 6 extra statements huh?
However I was making the solution far more complex last night then it needed
to be. Your version doesn't provide any encapsulation why should mine?
Since it will probably take me longer to explain I might as well just write
the alternate 20ish lines of boring code:
public struct Policy
{
static Policy policy;
public static Policy Current
{
get { return policy; }
set {
foreach(UserGroupAssignment ug in value.usergroups)
if ( Array.IndexOf(value.users, ug.user) < 0 ||
Array.IndexOf(value.groups, ug.group) < 0)
throw new ApplicationException();
policy = value;
}
}
public string[] users;
public string[] groups;
public UserGroupAssignment[] usergroups;
}
public struct UserGroupAssignment
{
public string user;
public string group;
}
Okay guess thats about 15, about the same as your table creation script
(dynamic languages that don't require strong types would reduce this
further, only 5 of these lines actually do anything at runtime). Clearly
there is not alot of code required, none of which is complex. Many
developers have more difficulty understanding how to use a SQL join then how
to use foreach loops, I'm sure you disagree but clearly neither solution is
*complex*.
How much further do you intend to insert foot in mouth?
- Kurt
"Kurt" <kurbylogic@hotmail.com> wrote in news:Q5adnSjM0IPdYN3fRVn- 2A@comcast.com: > How much further do you intend to insert foot in mouth? Oh Kurt, I just love it when you talk pompous.
|
|
0 |
|
Rich
3/23/2005 5:34:31 AM
"Costin Cozianu" <c_cozianu@hotmail.com> wrote in message news:3abslaF6adko7U1@individual.net... > Dmitry A. Kazakov wrote: >> On 22 Mar 2005 02:56:16 -0800, kurbylogic@hotmail.com wrote: >> >> >>>The database might be "thread-safe" but thread-saftey does not prevent >>>data in all cases from becoming inconsistant. >> >> >> = thread-unsafe >> >> >>>You refuse to add any more complexity to this task, yet bring up yet >>>bring up "deadlock detection" which isn't even remotely necessary in a >>>solution that requires no locks. >> >> >> ... wisely avoiding to mention either race condition elimination or the >> issue of meeting deadlines. >> >> I believe you are wasting your time. See my attempt at 11 March 2005... >> > > Actually FYI, you're repplying approvingly to something that was posted > from ignorance. Database has enough mechanisms to prevent data from > becoming incosistent, unlike the concurrency model in most programming > languages. > > That's why it is easy to meet deadlines when concurrent transactions are > handled by databases: that unlike OO code that has > > *no obvious concurrency related bugs* > > (such as is the case of the code posted by kurby, and as would probably be > the case with code posted by you along the lines you alluded to on 11 > March 2005), SQL databases provide the mechanisms (namely transaction and > isolation levels) that makes it easy to write code with > > *obviously no concurrency related bugs* > > Now which of the two properties is preferrable is left as an exercise for > the reader. Apperantly your understanding of issolation is limited. Yes the database does provide serializable issolation (if you are using less then serializable than you are not fully issolated and thus you are not thread-safe). There is however, a reason serializable is not the *default* issolation level, nor is it always appropriate, locking is a relatively expensive operation and long running serializable transaction will sevearly limit scalablility. In OO application a new object instance is fully issolated without any locks until it is shared or, in other words, "commited" (as apposed to the slightly lesser serializable issolation level that acheives full issolation using locks until commit). Directly from the documentation.: "READ COMMITTED Specifies that shared locks are held while the data is being read to avoid dirty reads, but the data can be changed before the end of the transaction, resulting in nonrepeatable reads or phantom data. This option is the SQL Server default." "SERIALIZABLE Places a range lock on the data set, preventing other users from updating or inserting rows into the data set until the transaction is complete. This is the most restrictive of the four isolation levels. Because concurrency is lower, use this option only when necessary. " Glossory definitions: "dirty read Reads that contain uncommitted data. For example, transaction1 changes a row. Transaction2 reads the changed row before transaction1 commits the change. If transaction1 rolls back the change, transaction2 has read a row that never logically existed." "nonrepeatable read When a transaction reads the same row more than one time, and between the two (or more) reads, a separate transaction modifies that row. Because the row was modified between reads within the same transaction, each read produces different values, which introduces inconsistency." "phantom By one task, the insertion of a new row or the deletion of an existing row in a range of rows previously read by another task that has not yet committed its transaction. The task with the uncommitted transaction cannot repeat its original read because of the change to the number of rows in the range. If a connection sets its transaction isolation level to serializable, SQL Server uses key-range locking to prevent phantoms." IMHO, concurrency issues are not any more obvious in a SQL then in OO. Have you ever joined the same table twice expeciting it to produce have the records as the first time? a subquery on same table or self join perhaps? Making all transactions serializable is *not a solution* for applications with scalability and performance requirements. In these types of applications it is also not uncommon to find queries with (nolock), choosing to accept a dirty read rather then the associated locking penalties. It is better to prevent a deadlock then it is to detect a deadlock, deadlock detection is not immediate usually leaving the transaction to hang or timeout waiting for a periodic deadlock search to be initiated (by a seperate thread). Deadlock detection does not make deadlocks a non-issue because when it happens the desired operation is not performed, so now you are left in a state where you must either retry the operation and hope that a deadlock will not reoccur, or choose to do something else; such as inform the user, "sorry your online order cannot be processed at this time please call us instead." If it happened once it will probably happen again, a couple months ago I found myself trying to track down a deadlock was occuring, usually 3-4 times during a nightly batch process that runs for over an hour; not something I want to do again. I would much rather debug an OO application where locking is explicit. Thats my opinion having done both, you probably would disagree, but since you haven't likely done it before I think it was a good idea for you to leave that as an excersise for the reader. - Kurt
Kurt wrote:
>>First fix your broken code and only after that take a grand standing
>>with such pompous statements.
>
>
> Ah yes, I suppose I intentionally omitted the *complex* part right? it was
> nearly 4 am when I coded that, thankfully because there is some
> encapsulation I can fix my solution without changing the client.
> Add the following before groups.Remove(group)
> foreach(user in users)
> if (UserIsInGroup(user, group)) RemoveUserFromGroup(user, group);
> And likewise for RemoveUser but looping over groups instead, clearly not
> complex, I think you can handle it.
>
> I suppose now after pointing out how you only need 35 lines of code you are
> going to make a big deal over these 6 extra statements huh?
> However I was making the solution far more complex last night then it needed
> to be. Your version doesn't provide any encapsulation why should mine?
> Since it will probably take me longer to explain I might as well just write
> the alternate 20ish lines of boring code:
>
> public struct Policy
> {
> static Policy policy;
> public static Policy Current
> {
> get { return policy; }
> set {
> foreach(UserGroupAssignment ug in value.usergroups)
> if ( Array.IndexOf(value.users, ug.user) < 0 ||
> Array.IndexOf(value.groups, ug.group) < 0)
> throw new ApplicationException();
> policy = value;
> }
> }
>
> public string[] users;
> public string[] groups;
> public UserGroupAssignment[] usergroups;
> }
> public struct UserGroupAssignment
> {
> public string user;
> public string group;
> }
>
> Okay guess thats about 15, about the same as your table creation script
> (dynamic languages that don't require strong types would reduce this
> further, only 5 of these lines actually do anything at runtime). Clearly
> there is not alot of code required, none of which is complex. Many
> developers have more difficulty understanding how to use a SQL join then how
> to use foreach loops, I'm sure you disagree but clearly neither solution is
> *complex*.
>
> How much further do you intend to insert foot in mouth?
>
> - Kurt
>
>
More broken code, Kurt ?
Not to mention that even if you fixed it somehow it wouldn't even begin
to remotely address the constraints of my challenge.
I'd rather recommend you trust your friendly database server to deal
with concurrency issues and spare yourself the embarassment of
overstepping your competence while bragging about it.
Kurt wrote: >>First fix your broken code and only after that take a grand standing >>with such pompous statements. > > > Ah yes, I suppose I intentionally omitted the *complex* part right? it was > nearly 4 am when I coded that, thankfully because there is some > encapsulation I can fix my solution without changing the client. > Add the following before groups.Remove(group) > foreach(user in users) > if (UserIsInGroup(user, group)) RemoveUserFromGroup(user, group); > And likewise for RemoveUser but looping over groups instead, clearly not > complex, I think you can handle it. > > I suppose now after pointing out how you only need 35 lines of code you are > going to make a big deal over these 6 extra statements huh? Add the above and the code is still broken. It is broken by design not by your lack of care to implementation details.
"Costin Cozianu" <c_cozianu@hotmail.com> wrote in message
news:3ade5bF65ltsrU1@individual.net...
> Kurt wrote:
>>>First fix your broken code and only after that take a grand standing
>>>with such pompous statements.
>>
>>
>> Ah yes, I suppose I intentionally omitted the *complex* part right? it
>> was nearly 4 am when I coded that, thankfully because there is some
>> encapsulation I can fix my solution without changing the client.
>> Add the following before groups.Remove(group)
>> foreach(user in users)
>> if (UserIsInGroup(user, group)) RemoveUserFromGroup(user, group);
>> And likewise for RemoveUser but looping over groups instead, clearly not
>> complex, I think you can handle it.
>>
>> I suppose now after pointing out how you only need 35 lines of code you
>> are going to make a big deal over these 6 extra statements huh?
>> However I was making the solution far more complex last night then it
>> needed to be. Your version doesn't provide any encapsulation why should
>> mine?
>> Since it will probably take me longer to explain I might as well just
>> write the alternate 20ish lines of boring code:
>>
>> public struct Policy
>> {
>> static Policy policy;
>> public static Policy Current
>> {
>> get { return policy; }
>> set {
>> foreach(UserGroupAssignment ug in value.usergroups)
>> if ( Array.IndexOf(value.users, ug.user) < 0 ||
>> Array.IndexOf(value.groups, ug.group) < 0)
>> throw new ApplicationException();
>> policy = value;
>> }
>> }
>>
>> public string[] users;
>> public string[] groups;
>> public UserGroupAssignment[] usergroups;
>> }
>> public struct UserGroupAssignment
>> {
>> public string user;
>> public string group;
>> }
>>
>> Okay guess thats about 15, about the same as your table creation script
>> (dynamic languages that don't require strong types would reduce this
>> further, only 5 of these lines actually do anything at runtime). Clearly
>> there is not alot of code required, none of which is complex. Many
>> developers have more difficulty understanding how to use a SQL join then
>> how to use foreach loops, I'm sure you disagree but clearly neither
>> solution is *complex*.
>>
>> How much further do you intend to insert foot in mouth?
>>
>> - Kurt
>
>
> More broken code, Kurt ?
>
> Not to mention that even if you fixed it somehow it wouldn't even begin to
> remotely address the constraints of my challenge.
Mine does not require cascading deletes to maintain concistancy, yours
does.
SQL cannot perform a simple yet arbitrary regular expression search, my
client can.
Yours does not always provide *better* then linear time. The overhead of
your non-existent solution in more practical scenario is likely to be
greater then mine, perhaps if you create an executable application that
actually performs the operations you say are "possible" we can compare
performance instead.
Your table creation script does not ensure "thread-safe" and "deadlock-safe"
usage, this is something your client (not included) must do (deadlock
detection is not deadlock safe rather only strengthens my argument that can
and do happen in a database)
Fix your code then I will "fix" mine.
- Kurt
>
> I'd rather recommend you trust your friendly database server to deal with
> concurrency issues and spare yourself the embarassment of overstepping
> your competence while bragging about it.
Kurt wrote:
> "Costin Cozianu" <c_cozianu@hotmail.com> wrote in message
> news:3ade5bF65ltsrU1@individual.net...
>
>>Kurt wrote:
>>
>>>>First fix your broken code and only after that take a grand standing
>>>>with such pompous statements.
>>>
>>>
>>>Ah yes, I suppose I intentionally omitted the *complex* part right? it
>>>was nearly 4 am when I coded that, thankfully because there is some
>>>encapsulation I can fix my solution without changing the client.
>>>Add the following before groups.Remove(group)
>>>foreach(user in users)
>>> if (UserIsInGroup(user, group)) RemoveUserFromGroup(user, group);
>>>And likewise for RemoveUser but looping over groups instead, clearly not
>>>complex, I think you can handle it.
>>>
>>>I suppose now after pointing out how you only need 35 lines of code you
>>>are going to make a big deal over these 6 extra statements huh?
>>>However I was making the solution far more complex last night then it
>>>needed to be. Your version doesn't provide any encapsulation why should
>>>mine?
>>>Since it will probably take me longer to explain I might as well just
>>>write the alternate 20ish lines of boring code:
>>>
>>> public struct Policy
>>> {
>>> static Policy policy;
>>> public static Policy Current
>>> {
>>> get { return policy; }
>>> set {
>>> foreach(UserGroupAssignment ug in value.usergroups)
>>> if ( Array.IndexOf(value.users, ug.user) < 0 ||
>>>Array.IndexOf(value.groups, ug.group) < 0)
>>> throw new ApplicationException();
>>> policy = value;
>>> }
>>> }
>>>
>>> public string[] users;
>>> public string[] groups;
>>> public UserGroupAssignment[] usergroups;
>>> }
>>> public struct UserGroupAssignment
>>> {
>>> public string user;
>>> public string group;
>>> }
>>>
>>>Okay guess thats about 15, about the same as your table creation script
>>>(dynamic languages that don't require strong types would reduce this
>>>further, only 5 of these lines actually do anything at runtime). Clearly
>>>there is not alot of code required, none of which is complex. Many
>>>developers have more difficulty understanding how to use a SQL join then
>>>how to use foreach loops, I'm sure you disagree but clearly neither
>>>solution is *complex*.
>>>
>>>How much further do you intend to insert foot in mouth?
>>>
>>>- Kurt
>>
>>
>>More broken code, Kurt ?
>>
>>Not to mention that even if you fixed it somehow it wouldn't even begin to
>>remotely address the constraints of my challenge.
>
>
> Mine does not require cascading deletes to maintain concistancy, yours
> does.
You call that a feature ? Shifting complexity to the client context
instead of simply declaring a ON CASCADE DELETE.
Your code does not maintain any kind of consistency. SQL can surely do
that as well, even a high-school student writing his first program in
Basic can do that, no problem.
> SQL cannot perform a simple yet arbitrary regular expression search, my
> client can.
Yes, you can say that incompetent trolls don't know how to use regular
expression in SQL queries. Hardly a problem attributable to SQL
> Yours does not always provide *better* then linear time. The overhead of
> your non-existent solution in more practical scenario is likely to be
> greater then mine, perhaps if you create an executable application that
> actually performs the operations you say are "possible" we can compare
> performance instead.
Well, sure you can complainn that the overhead of DBMS being out of
process but that disappears when you use embedded SQL libraries if you
really need to. However, the trade-off of a real DBMS is that the same
information can be easily and safely accessed by different processes.
This discussion has nothing to do with you bailing out from the
requirement to provide a better than linear search time.
> Your table creation script does not ensure "thread-safe" and "deadlock-safe"
> usage, this is something your client (not included) must do (deadlock
> detection is not deadlock safe rather only strengthens my argument that can
> and do happen in a database)
>
Actually if you want to play with words you can play, but the ridiculous
quality of your code is still left behind.
Yes, users can sometimes deadlock each other by requiring access to
resources in all kinds of orders. Transaction can fail for one reason or
the other, including an overzealous database server. This is inherent to
any distributed system. Software systems need to deal gracefully with
all kinds of failures, cause the mechanism to write perfect software
that never fails has not been invented just yet.
The difference is that with a DBMS one transaction is rolled back,
overall progress is being made, data is left in a consistent state. The
system overall is never deadlocked.
With the typical mistakes that happen everyday when OO developers write
concurrent software the choice is between :
1) a deadlock without user recourse, sometimes even paralyzing the whole
system
2) inconsistent data.
3) have developers that write perfect software
Your code in both solutions avoids the deadlock by choosing to expose
users to inconsistent data.
> Fix your code then I will "fix" mine.
>
> - Kurt
>
If you don't fix it, then I guess there's nothing left to discuss.
"Costin Cozianu" <c_cozianu@hotmail.com> wrote in message
news:3aekn7F6aj1v3U1@individual.net...
> Kurt wrote:
>> "Costin Cozianu" <c_cozianu@hotmail.com> wrote in message
>> news:3ade5bF65ltsrU1@individual.net...
>>
>>>Kurt wrote:
>>>
>>>>>First fix your broken code and only after that take a grand standing
>>>>>with such pompous statements.
>>>>
>>>>
>>>>Ah yes, I suppose I intentionally omitted the *complex* part right? it
>>>>was nearly 4 am when I coded that, thankfully because there is some
>>>>encapsulation I can fix my solution without changing the client.
>>>>Add the following before groups.Remove(group)
>>>>foreach(user in users)
>>>> if (UserIsInGroup(user, group)) RemoveUserFromGroup(user, group);
>>>>And likewise for RemoveUser but looping over groups instead, clearly not
>>>>complex, I think you can handle it.
>>>>
>>>>I suppose now after pointing out how you only need 35 lines of code you
>>>>are going to make a big deal over these 6 extra statements huh?
>>>>However I was making the solution far more complex last night then it
>>>>needed to be. Your version doesn't provide any encapsulation why should
>>>>mine?
>>>>Since it will probably take me longer to explain I might as well just
>>>>write the alternate 20ish lines of boring code:
>>>>
>>>> public struct Policy
>>>> {
>>>> static Policy policy;
>>>> public static Policy Current
>>>> {
>>>> get { return policy; }
>>>> set {
>>>> foreach(UserGroupAssignment ug in value.usergroups)
>>>> if ( Array.IndexOf(value.users, ug.user) < 0 ||
>>>> Array.IndexOf(value.groups, ug.group) < 0)
>>>> throw new ApplicationException();
>>>> policy = value;
>>>> }
>>>> }
>>>>
>>>> public string[] users;
>>>> public string[] groups;
>>>> public UserGroupAssignment[] usergroups;
>>>> }
>>>> public struct UserGroupAssignment
>>>> {
>>>> public string user;
>>>> public string group;
>>>> }
>>>>
>>>>Okay guess thats about 15, about the same as your table creation script
>>>>(dynamic languages that don't require strong types would reduce this
>>>>further, only 5 of these lines actually do anything at runtime).
>>>>Clearly there is not alot of code required, none of which is complex.
>>>>Many developers have more difficulty understanding how to use a SQL join
>>>>then how to use foreach loops, I'm sure you disagree but clearly neither
>>>>solution is *complex*.
>>>>
>>>>How much further do you intend to insert foot in mouth?
>>>>
>>>>- Kurt
>>>
>>>
>>>More broken code, Kurt ?
>>>
>>>Not to mention that even if you fixed it somehow it wouldn't even begin
>>>to remotely address the constraints of my challenge.
>>
>>
>> Mine does not require cascading deletes to maintain concistancy, yours
>> does.
>
> You call that a feature ? Shifting complexity to the client context
> instead of simply declaring a ON CASCADE DELETE.
Okay, I can accept that, add back in the remove user/remove user functions.
You've shifted thread-saftey and deadlock prevention to the client, fix
yours.
>
> Your code does not maintain any kind of consistency. SQL can surely do
> that as well, even a high-school student writing his first program in
> Basic can do that, no problem.
>
>> SQL cannot perform a simple yet arbitrary regular expression search, my
>> client can.
>
> Yes, you can say that incompetent trolls don't know how to use regular
> expression in SQL queries. Hardly a problem attributable to SQL
Write me a query that will find all groups which have a that have a have the
same word or phrase more then once, first without () then within paren:
"Accounting (Accounting)" this was an error in an import script so we want
to remove these, however "Billing (Accounting)" is okay.
>
>> Yours does not always provide *better* then linear time. The overhead of
>> your non-existent solution in more practical scenario is likely to be
>> greater then mine, perhaps if you create an executable application that
>> actually performs the operations you say are "possible" we can compare
>> performance instead.
>
> Well, sure you can complainn that the overhead of DBMS being out of
> process but that disappears when you use embedded SQL libraries if you
> really need to. However, the trade-off of a real DBMS is that the same
> information can be easily and safely accessed by different processes.
> This discussion has nothing to do with you bailing out from the
> requirement to provide a better than linear search time.
>
Fix yours.
I can replace my string[]s with a (out-of the box) collection that uses
b-tree, its not that hard, I promise.
>> Your table creation script does not ensure "thread-safe" and
>> "deadlock-safe" usage, this is something your client (not included) must
>> do (deadlock detection is not deadlock safe rather only strengthens my
>> argument that can and do happen in a database)
>>
>
> Actually if you want to play with words you can play, but the ridiculous
> quality of your code is still left behind.
You mean the ridiculous simplicity, yours provides no encapsulation, why
should mine?
>
> Yes, users can sometimes deadlock each other by requiring access to
> resources in all kinds of orders. Transaction can fail for one reason or
> the other, including an overzealous database server. This is inherent to
> any distributed system. Software systems need to deal gracefully with all
> kinds of failures, cause the mechanism to write perfect software that
> never fails has not been invented just yet.
>
> The difference is that with a DBMS one transaction is rolled back, overall
> progress is being made, data is left in a consistent state. The system
> overall is never deadlocked.
>
> With the typical mistakes that happen everyday when OO developers write
> concurrent software the choice is between :
> 1) a deadlock without user recourse, sometimes even paralyzing the whole
> system
> 2) inconsistent data.
> 3) have developers that write perfect software
>
> Your code in both solutions avoids the deadlock by choosing to expose
> users to inconsistent data.
Wrong, Policy.Current is always valid, modifications to that object cannot
affect another user until Policy.Current is replaced, the new policy is
ensured by to be valid by the property set method.
>
>
>> Fix your code then I will "fix" mine.
>>
>> - Kurt
>>
>
>
> If you don't fix it, then I guess there's nothing left to discuss.
When you withdrawl your assumption that your code satisfies all of these
constraints and fix your code, then I will fix mine.
- Kurt
"kurbylogic@hotmail.com" <kurbylogic@hotmail.com> wrote in message news:<1111488976.454766.187380@o13g2000cwo.googlegroups.com>... > The point I wanted to make is that one should choose the correct tool > for the correct task... And OO is not the correct tool for data management. > in OO the > complexity of mapping database tables to objects is useful only if the > object has behavior, An object always has behavior. > such as Loan.Approve() that involves more then > just updating a field. It would be a lot better to do this: update Loans set Approved = true where Id = ... The Loan class and the Approve() method are superfluous. > If all you want to do is create a list of users > and groups and maintain some relationship between them then an OO > solution has little value Like in any data management scenario. > and given the choice between a database or OO > solution to the problem I too would use the database, You would use the DBMS. > nearly every > application I write anymore involves a database as part of the > solution, but a database alone cannot provide a complete end-to-end > solution. It is clear that when you say database you mean DBMS, and a DBMS might provide a complete end-to-end solution. > The database might be "thread-safe" but thread-saftey does not prevent > data in all cases from becoming inconsistant. Of course! What a silly statement! > It is not thread-saftey alone that ensures data > concistancy, it must be coupled with issolation, issolation is the > easiest and probably most common OO approach to concurrency issues in > object solutions But such isolation does not work with shared data sources. > all. This is not true with the database where inserts that have not > yet commited can be seen by other or users Only whether you are using the "dirty-reads" "isolation" level. That does not happen with the default configuration (read commited) of any SQL-DBMS. > So in response to your initial challenge, the following addresses ONLY > your solution as you insist and is thread safe (policy class does not > need to be thread safe because a thread can only get an instance of it > via new Policy() Astonishing! So what about the other threads? > or from the SecurityManager which returns a new > instance with a copy of the current state therefore it is issolated > from other threads and does not require any locking) So it is thread safe because it does not support multi-threading. Great! > You refuse to add any more complexity to this task, yet bring up yet > bring up "deadlock detection" which isn't even remotely necessary in a > solution that requires no locks. This problem requires locks. > It is only slightly longer than your table creation script, but you did > not include any procedure creation scripts What procedures? It is not necessary to write any procedure to solve this problem. >therefore I assume that you > must expect the client to query the user/group tables directly... Of course! So what! That's the way to work with an SQL DBMS. > If/When we decied to add groups into groups all changes are issolated > to the policy class, you would have to update all of your "only one > statement..." in dozens if not hundreds of locations Plain nonsense. > Relational databases aren't going away, but not because they are less > complex. Nonsense. > I guess you can call SQL is a "high-level" language, its > purpose is however different, it is a set oriented language it works > well with sets of structured data Data is structured by definition. >, OO languages provide polymorphic > behavior which you deny even exists, He meant that this is meaningless pap. > So if you are going to complain an > many-many relationship in OO is *too complex* (which of the 35 lines > was complex?) then abandon OO write all your business logic in in SQL, Many peoply write all their business logic in SQL! But OO still might be useful for the presentation logic! > why can't I say load the current state of the > system without having to reconstruct object graphs from dozens of > seperate tables. You can, but that is a blunder. > If persistance was the only useful service provided > by a relational database then I suppose more persistant memory is all > one would need. But obviously you are not interested in the > big-picture just the overwelming complexity in the 35 lines of code to > implement a many-many user group relationship. Where do you want to go with this? > Someone who does not see value in an OO language either because he > refuses to or cannot face the inevitable complexity of any real > application The complexity of your broken code can be avoided with a DBMS, and it would work. >, or because the "complexity" of a many-many relationship is > too much to handle It seems that it is too much for you, but it is absolutely trivial using an RDBMS. >, than I couldn't possible expect him to see any > value in an object database either. That's really funny. Do you mean the utterly discredited OODBMS's of the 90's? Regards
"Kurt" <kurbylogic@hotmail.com> wrote in message news:<LoqdnQ0wpeTshd_fRVn-qA@comcast.com>... > Mine does not require cascading deletes to maintain concistancy, yours > does. Yours does not maintain consistency because you don't perform cascading deletes. > SQL cannot perform a simple yet arbitrary regular expression search, my > client can. It seems that you know very little about SQL. > Yours does not always provide *better* then linear time. Yours never provide better than linear time. > The overhead of > your non-existent solution in more practical scenario is likely to be > greater then mine His solution is correct, complete, efficient and executable. Yours is none of the above. > Your table creation script does not ensure "thread-safe" and "deadlock-safe" The DBMS ensures that. Regards
Kurt wrote: >>Your code in both solutions avoids the deadlock by choosing to expose >>users to inconsistent data. > > > Wrong, Policy.Current is always valid, modifications to that object cannot > affect another user until Policy.Current is replaced, the new policy is > ensured by to be valid by the property set method. > > Hmmm, interesting. Are you trolling or simply incompetent? Let's assume that in the heat of trying to "prove" something you don't use your best judgement, and in reality you can have more objective assessments about your code. But if you see nothing wrong with your design, please let us know how the client context, say the UI, goes about (1)creating a new group, (2) removing a group, (3) creating a user (4)removing a user in the system.
Costin Cozianu wrote:
> I'm waiting to see how OO weenies out there put their code where
their
> mouth is.
I was playing with ZODB today and I thought of you :)
Here's Groups and Users implemented in Python with ZODB:
class User(Persistent):
def __init__(self, name = None):
self.name = name
self.groups = LinkedSet(self, "users")
class Group(Persistent):
def __init__(self, name = None):
self.name = name
self.users = LinkedSet(self, "groups")
Here's the the seven statements from your SQL solution:
def example(dbroot):
userdb = getDb(dbroot, 'userdb')
groupdb = getDb(dbroot, 'groupdb')
transaction.begin()
try:
#1) creating a user
userdb['John'] = User('John')
#2) creating a group
groupdb['Administrator'] = Group('Administrator')
john = userdb['John']
adminGroup = groupdb['Administrator']
#3) associating a user with a group
adminGroup.users.add(john)
#4) removing the association between a user and a group
adminGroup.users.remove(john)
#5) deleting a user
del userdb['John']
#6) deleting a group
del groupdb['Administrator']
# we even have transactions!!!
transaction.commit()
except:
transaction.abort()
#7) selecting users or groups based on simple criteria
results = [user for user in userdb.values() if user.name == 'John']
results = [group for group in groupdb.values() if group.name ==
'Administrator']
The full executable Python file is included below. You'll need Python
2.3 and ZODB installed. Throw in ZEO for a multi user system.
Regards,
John
from ZODB import FileStorage, DB
import transaction
from persistent import Persistent
from sets import Set
class LinkedSet(Set):
def __init__(self, source, relatedAttribute):
Set.__init__(self)
self.source = source
self.relatedAttribute = relatedAttribute
def add(self, item):
Set.add(self, item)
Set.add(getattr(item, self.relatedAttribute), self.source)
self.source._p_changed = True
def discard(self, item):
Set.discard(self, item)
Set.discard(getattr(item, self.relatedAttribute), self.source)
self.source._p_changed = True
class User(Persistent):
def __init__(self, name = None):
self.name = name
self.groups = LinkedSet(self, "users")
class Group(Persistent):
def __init__(self, name = None):
self.name = name
self.users = LinkedSet(self, "groups")
def getDb(dbroot, name):
if not dbroot.has_key(name):
from BTrees.OOBTree import OOBTree
dbroot[name] = OOBTree()
return dbroot[name]
def example(dbroot):
userdb = getDb(dbroot, 'userdb')
groupdb = getDb(dbroot, 'groupdb')
transaction.begin()
try:
#1) creating a user
userdb['John'] = User('John')
#2) creating a group
groupdb['Administrator'] = Group('Administrator')
john = userdb['John']
adminGroup = groupdb['Administrator']
#3) associating a user with a group
adminGroup.users.add(john)
#4) removing the association between a user and a group
adminGroup.users.remove(john)
#5) deleting a user
del userdb['John']
#6) deleting a group
del groupdb['Administrator']
# we even have transactions!!!
transaction.commit()
except:
transaction.abort()
#7) selecting users or groups based on simple criteria
results = [user for user in userdb.values() if user.name == 'John']
results = [group for group in groupdb.values() if group.name ==
'Administrator']
if __name__ == '__main__':
storage = FileStorage.FileStorage('/temp/test.fs')
db = DB(storage)
conn = db.open()
try:
example(conn.root())
finally:
db.close()
John Urberg wrote:
> Costin Cozianu wrote:
>
>>I'm waiting to see how OO weenies out there put their code where
>
> their
>
>>mouth is.
>
>
> I was playing with ZODB today and I thought of you :)
>
> Here's Groups and Users implemented in Python with ZODB:
>
> class User(Persistent):
> def __init__(self, name = None):
> self.name = name
> self.groups = LinkedSet(self, "users")
>
> class Group(Persistent):
> def __init__(self, name = None):
> self.name = name
> self.users = LinkedSet(self, "groups")
>
> Here's the the seven statements from your SQL solution:
>
> def example(dbroot):
> userdb = getDb(dbroot, 'userdb')
> groupdb = getDb(dbroot, 'groupdb')
>
> transaction.begin()
> try:
>
> #1) creating a user
> userdb['John'] = User('John')
>
> #2) creating a group
> groupdb['Administrator'] = Group('Administrator')
>
> john = userdb['John']
> adminGroup = groupdb['Administrator']
>
> #3) associating a user with a group
> adminGroup.users.add(john)
>
> #4) removing the association between a user and a group
> adminGroup.users.remove(john)
>
> #5) deleting a user
> del userdb['John']
>
> #6) deleting a group
> del groupdb['Administrator']
>
> # we even have transactions!!!
> transaction.commit()
> except:
> transaction.abort()
>
> #7) selecting users or groups based on simple criteria
> results = [user for user in userdb.values() if user.name == 'John']
> results = [group for group in groupdb.values() if group.name ==
> 'Administrator']
>
> The full executable Python file is included below. You'll need Python
> 2.3 and ZODB installed. Throw in ZEO for a multi user system.
>
> Regards,
> John
>
How nice of you, now I have to readup on ZODB and this ZEO multi-user
system, as well as brush my Python :)
Thanks though.
Best,
Costin
John Urberg wrote:
> Costin Cozianu wrote:
>
>>I'm waiting to see how OO weenies out there put their code where
>
> their
>
>>mouth is.
>
>
> I was playing with ZODB today and I thought of you :)
>
> Here's Groups and Users implemented in Python with ZODB:
>
> class User(Persistent):
> def __init__(self, name = None):
> self.name = name
> self.groups = LinkedSet(self, "users")
>
> class Group(Persistent):
> def __init__(self, name = None):
> self.name = name
> self.users = LinkedSet(self, "groups")
>
> Here's the the seven statements from your SQL solution:
>
> def example(dbroot):
> userdb = getDb(dbroot, 'userdb')
> groupdb = getDb(dbroot, 'groupdb')
>
> transaction.begin()
> try:
>
> #1) creating a user
> userdb['John'] = User('John')
>
> #2) creating a group
> groupdb['Administrator'] = Group('Administrator')
>
> john = userdb['John']
> adminGroup = groupdb['Administrator']
>
> #3) associating a user with a group
> adminGroup.users.add(john)
>
> #4) removing the association between a user and a group
> adminGroup.users.remove(john)
>
> #5) deleting a user
> del userdb['John']
>
> #6) deleting a group
> del groupdb['Administrator']
>
> # we even have transactions!!!
> transaction.commit()
> except:
> transaction.abort()
>
> #7) selecting users or groups based on simple criteria
> results = [user for user in userdb.values() if user.name == 'John']
> results = [group for group in groupdb.values() if group.name ==
> 'Administrator']
>
> The full executable Python file is included below. You'll need Python
> 2.3 and ZODB installed. Throw in ZEO for a multi user system.
>
> Regards,
> John
>
> from ZODB import FileStorage, DB
> import transaction
> from persistent import Persistent
> from sets import Set
>
> class LinkedSet(Set):
> def __init__(self, source, relatedAttribute):
> Set.__init__(self)
> self.source = source
> self.relatedAttribute = relatedAttribute
> def add(self, item):
> Set.add(self, item)
> Set.add(getattr(item, self.relatedAttribute), self.source)
> self.source._p_changed = True
> def discard(self, item):
> Set.discard(self, item)
> Set.discard(getattr(item, self.relatedAttribute), self.source)
> self.source._p_changed = True
>
> class User(Persistent):
> def __init__(self, name = None):
> self.name = name
> self.groups = LinkedSet(self, "users")
>
> class Group(Persistent):
> def __init__(self, name = None):
> self.name = name
> self.users = LinkedSet(self, "groups")
>
> def getDb(dbroot, name):
> if not dbroot.has_key(name):
> from BTrees.OOBTree import OOBTree
> dbroot[name] = OOBTree()
> return dbroot[name]
>
> def example(dbroot):
> userdb = getDb(dbroot, 'userdb')
> groupdb = getDb(dbroot, 'groupdb')
>
> transaction.begin()
> try:
>
> #1) creating a user
> userdb['John'] = User('John')
>
> #2) creating a group
> groupdb['Administrator'] = Group('Administrator')
>
> john = userdb['John']
> adminGroup = groupdb['Administrator']
>
> #3) associating a user with a group
> adminGroup.users.add(john)
>
> #4) removing the association between a user and a group
> adminGroup.users.remove(john)
>
> #5) deleting a user
> del userdb['John']
>
> #6) deleting a group
> del groupdb['Administrator']
>
> # we even have transactions!!!
> transaction.commit()
> except:
> transaction.abort()
>
> #7) selecting users or groups based on simple criteria
> results = [user for user in userdb.values() if user.name == 'John']
> results = [group for group in groupdb.values() if group.name ==
> 'Administrator']
>
> if __name__ == '__main__':
> storage = FileStorage.FileStorage('/temp/test.fs')
> db = DB(storage)
> conn = db.open()
> try:
> example(conn.root())
> finally:
> db.close()
>
Now I am not claiming that I understand a lot about Python in
conjunction with ZODB, but I believe you may need to add
an
item._p_changed=true
to the methods in LinkedSet class. Is it the case that the notation
Class.method(object, ... ) denotes a non-polymorphic call ?
I'm not nitpicking, but I need to check I got things right about your
code, given my amateurish Python.
I'd also like to sketch (or point me to to the right docs) how
del userdb['John']
triggers the removal of John from all the groups he was part of. And
obviously the symmetrical
del groupdb['Administrator']
As for the concurrency model of ZODB, I couldn't find a very clear
documentation just yet, but still digging. It looks like some form of
optimistic locking, but details are kind of lacking. Maybe the
definitive reference is the source code.
"Costin Cozianu" <c_cozianu@hotmail.com> wrote in message news:3ag02kF6b3vgoU1@individual.net... > Kurt wrote: >>>Your code in both solutions avoids the deadlock by choosing to expose >>>users to inconsistent data. >> >> >> Wrong, Policy.Current is always valid, modifications to that object >> cannot affect another user until Policy.Current is replaced, the new >> policy is ensured by to be valid by the property set method. >> > > Hmmm, interesting. Are you trolling or simply incompetent? > > Let's assume that in the heat of trying to "prove" something you don't use > your best judgement, and in reality you can have more objective > assessments about your code. You are the one that made the absurd claim I'm just showing you how simple can be. The only constraint not met yet is the better than linear search time, a call to Array.Sort or a SortedList and you'll have no problem getting better then linear search time, all your constraints would be met. So as far as an objective assesment, is this the way that I would do it? The short version hell no I believe in concepts such as encapsulation, first version might be okay in the simplest of requirements. There are few things that need improvement to make it all that useful in a practical application. Conflicting updates are not checked (not a constraint, yours doesn't do it either, I'm sure you wont believe me till I actually write a couple SQL scripts to demonstrate it but anyways) and copying the entire policy structure on every get/set is not the most efficient way to go about it... a few hundred users it would be fine, modification of a million records (unlikely as that is for users and groups) would be rather slow. However, without an application driving the requirements there is no need for this code to exist, and thus for this pointless excersise, the *simplest thing* is good enough. For all practical purposes its as worthless as yours. You are the one who was *insisting* on not adding unnecessary complexity, so there it is the simplest thing that could work. > > But if you see nothing wrong with your design, please let us know how the > client context, say the UI, goes about (1)creating a new group, (2) > removing a group, (3) creating a user (4)removing a user in the system. > Since all the members are public, nothing is stopping the client from modify the array (reallocation probably necessary unless you do something clever like allocate a larger array in the first place). Programming 101, if you can't figure it out use the slightly longer version its has methods that do this for you. It's not much different then updating or inserting into a table. I'm not against databases, I use them all the time.... the "complexity" of OO isn't the reason. Most of our reports are unfortunatly written in the database, the sprocs involved are a around a couple thousand lines of code (several thousand lines if you include code for the functions used), they are far more complex then OO code that creates and manipulates that data in the first place, sub-accounts need to be rolled up to the parent, currency conversion must be performed, and a number of other rather trivial functions in the OO application become massive chucks of sql code. The only reason they are implemented in the database is because it is too inefficent to send several hundred thousand records to the application for processing. Most database objects have simalar OO representation in the application, if the database only provided query services and persistance or memory size wasn't an issue, then in my opinion a database would just add unecessary complexity to the application... despite many-many relationships which do exist in our application, they are the least of my concerns. Your claim to me is completely absurd, not to mention rather irrelevant as persistance and memory size are still valid application concerns. I didn't expect I would have go as far as explaining array manipulation from programming 101. I don't know why I'm wasting my time, other then becuase of the utter stupidity of your first comment, I guess I enjoyed watching you publicly display your stupidity. I know that is rather small of me, but I'm loosing interest and this pointless code isn't worth defending, its simplest thing that could work, no more no less. - Kurt
Hi, Alfredo Novoa wrote: [snip] > An object always has behavior. > > >>such as Loan.Approve() that involves more then >>just updating a field. > > > It would be a lot better to do this: > > update Loans set Approved = true where Id = ... > > The Loan class and the Approve() method are superfluous. > IMO it's worse: you have business logic (loan.aprove()) and search/find logic (where id=...) mixed together. It can change for differnet reasons (i.e. pk changed) so it should be separated. Regards Michal
kleks2Kurt wrote: <useless handwaving skipped> > > > - Kurt > > Cut the crap, Kurt, will you ? Your code is simply broken beyond redemption. It's not simplest that could work, because it doesn't, it's thread unsafe.If you cannot understand this smple fact about your code, it's useless to waste my time with yet another stupid troll that hinds behind the bushes. In case you just cannot think for yourself at all, let give you a hint: try to run two concurrent threads, one will add a user and one would add a group. Or even better, one would add a group and one would delete a user. Then after you prove that they interfere, you'll be left either trolling me that there's a good reason for it, or throwing more idiotic statements about your misunderstanding of SQL by the way of counter-attack, in which case I'm letting you know I won't bother to feed your trolls, or admitting that you were wrong and maybe taking a half baked, ad-hoc patch to salvage your crappy idea that if assignments are atomic that alone can make your scheme thread safe. Actually you're the best argument for which managers will keep buying Oracle. You can trust programmers to write a bunch of SQL statements, you can even trust them with single threaded OO code, but when it comes to multi-threaded they are absolutely clueless. Not only incompetent but unaware of it, sometimes even proud by what they think is their competence. Incompetent and proud of it. So that's why we have the current models like EJB or .NET three tier and everything, where the programmer's code is confined to an environment that is as if single threaded (several threads run in parallel but no programmer accessible state is shared between threads) and everything is tunneled to the database who is the ultimate maintainer of state under concurrency. Because otherwise, left to their own devices, they'd be producing crap like yours and claim it to be safe, when it ain't. The consequences would be devastating. So it is just plain good business to confine developers within their limited area of competence (which doesn't even begin to cover writing concurrent code).
Costin Cozianu wrote:
> Now I am not claiming that I understand a lot about Python in
> conjunction with ZODB, but I believe you may need to add
> an
> item._p_changed=true
> to the methods in LinkedSet class. Is it the case that the notation
> Class.method(object, ... ) denotes a non-polymorphic call ?
>
> I'm not nitpicking, but I need to check I got things right about your
> code, given my amateurish Python.
>
> I'd also like to sketch (or point me to to the right docs) how
> del userdb['John']
> triggers the removal of John from all the groups he was part of. And
> obviously the symmetrical
> del groupdb['Administrator']
You made some good catches for an amateur at Python. Yes I need to add
item._p_changed = True. I also forgot to add code to remove groups the
user is a part of and vice versa. But what do you expect from code
written in 15 min over lunch? :)
After an additional utility class and a change to LinkedSet, User and
Group now look as follows:
class User(Persistent):
def __init__(self, name = None):
self.name = name
self.groups = LinkedSet(self, "users")
def onDelete(self):
self.groups.clear()
class Group(Persistent):
def __init__(self, name = None):
self.name = name
self.users = LinkedSet(self, "groups")
def onDelete(self):
self.users.clear()
The example function remains the same. The full executable code
follows.
Regards,
John
#=============================================
from BTrees.OOBTree import OOBTree
from ZODB import FileStorage, DB
import transaction
from persistent import Persistent
from sets import Set
class ExtendedOOBTree(OOBTree):
def __init__(self):
OOBTree.__init__(self)
def __delitem__(self, key):
item = self[key]
item.onDelete()
OOBTree.__delitem__(self, key)
def getDb(dbroot, name):
if not dbroot.has_key(name):
dbroot[name] = ExtendedOOBTree()
return dbroot[name]
class LinkedSet(Set):
def __init__(self, source, relatedAttribute):
Set.__init__(self)
self.source = source
self.relatedAttribute = relatedAttribute
def add(self, item):
Set.add(self, item)
Set.add(getattr(item, self.relatedAttribute), self.source)
self.source._p_changed = True
item._p_changed = True
def discard(self, item):
Set.discard(self, item)
Set.discard(getattr(item, self.relatedAttribute), self.source)
self.source._p_changed = True
item._p_changed = True
def clear(self):
for item in self:
Set.discard(getattr(item, self.relatedAttribute),
self.source)
item._p_changed = True
Set.clear(self)
self.source._p_changed = True
class User(Persistent):
def __init__(self, name = None):
self.name = name
self.groups = LinkedSet(self, "users")
def onDelete(self):
self.groups.clear()
class Group(Persistent):
def __init__(self, name = None):
self.name = name
self.users = LinkedSet(self, "groups")
def onDelete(self):
self.users.clear()
# Here's an example showing how the client is exactly '''one'''
statement away from:
def example(dbroot):
userdb = getDb(dbroot, 'userdb')
groupdb = getDb(dbroot, 'groupdb')
transaction.begin()
try:
#1) creating a user
userdb['John'] = User('John')
#2) creating a group
groupdb['Administrator'] = Group('Administrator')
john = userdb['John']
adminGroup = groupdb['Administrator']
#3) associating a user with a group
adminGroup.users.add(john)
#4) removing the association between a user and a group
adminGroup.users.remove(john)
#5) deleting a user
del userdb['John']
#6) deleting a group
del groupdb['Administrator']
# we even have transactions!!!
transaction.commit()
except Exception, e:
transaction.abort()
raise e
#7) selecting users or groups based on simple criteria
results = [user for user in userdb.values() if user.name == 'John']
results = [group for group in groupdb.values() if group.name ==
'Administrator']
# If you have Python 2.3 and ZODB, just create a temp directory and
run.
# If you want multi user capabilities, you'll need to setup a ZEO
server
if __name__ == '__main__':
storage = FileStorage.FileStorage('/temp/test.fs')
db = DB(storage)
conn = db.open()
try:
example(conn.root())
finally:
db.close()
Hi, Michal Kleczek <kleks2@wp.pl> wrote in message news:<d213k1$aiu$1@nemesis.news.tpi.pl>... > > It would be a lot better to do this: > > > > update Loans set Approved = true where Id = ... > > > > The Loan class and the Approve() method are superfluous. > > > > IMO it's worse: > you have business logic (loan.aprove()) > and search/find logic (where id=...) mixed together. No, you should not see a relational query from a file processing perspective. It is 100% business logic it has nothing to do with search and find. (where id=...) is a way to identify the tuple we want to update, and it is a lot better than to identify an object using a pointer. The relational solution is very close to natural language. > It can change for differnet reasons > (i.e. pk changed) so it should be separated. A loan's identifier never changes. Regards
Michal Kleczek wrote: > you have business logic (loan.aprove()) > and search/find logic (where id=...) mixed together. > It can change for differnet reasons > (i.e. pk changed) so it should be separated. Can you give some examples of why "business logic" and "search/find logic" can be changed for different reasons? Do you have an example of primary key change, where separation would have isolated the change only to the "search/find logic" layer? Fredrik Bertilsson http://butler.sourceforge.net
On Wed, 09 Mar 2005 13:06:10 -0800, Costin Cozianu <c_cozianu@hotmail.com>
wrote:
> it should be usable from the calling context without any fear of
> deadlock or spurious results in a multi-threaded environment. Again,
> persistence is not an issue -- data need not be persisted (imagine you
> had your nvram or whatever).
Ive been pondering the transaction/multi-threaded aspect of this issue
and its occured to me that many of problems an RDMS needs to solve do
to some extent arise, or at least are made significantly worse, because
the DBMS exists as a system that lives apart from the application.
Parallelism is one such example. The latency and load characteristics
of an RDBMS mean that almost no useful system can be written without
allowing some degree of parallel access. If we just serialise all access,
we end up with a system whose capacity is severly limited by cumulative
IO latency effects rather than by actual computational resources.
In some cases the latency of a query evaluation may be great enough to
compromise response requirements of other updates etc. This is one of
the reasons why we use transactions.
The characteristics of a in-memory model are completely different however.
Here a single model operation is able to utilise 100% computational
capacity
with no IO latency overhead. Thus it is entirely resonable to simply
serialise all model operations.
So my code for handling all threading and deadlock issues is:
syncronize(this) {
...
// do update here
...
}
:)
Paul C.
|
|
0 |
|
paul
3/28/2005 11:16:17 AM
paul campbell wrote:
> The characteristics of a in-memory model are completely different
however.
> Here a single model operation is able to utilise 100% computational
> capacity
Really? Why would the locking functionality behaive different in an
in-memory model? A RDBMS locks the record after a write (and read
depending on the isolation level) and releases the lock after
commit/rollback. Would a in-memory model do this different?
> So my code for handling all threading and deadlock issues is:
> syncronize(this) {
> ...
> // do update here
> ...
> }
What object is "this"? I am afraid that "this" is a service object and
then you will disable all parallell access to that service. Your
solution will disable parallell access much more than an RDBMS. Your
entire transaction has to be included in a synchronize block and no
other threads will be able to execute this block until the first thread
has completed. A RBDMS will only lock the effected records, not your
service.
Fredrik Bertilsson
http://butler.sourceforge.net
On 28 Mar 2005 04:42:40 -0800, frebe <fredrik_bertilsson@passagen.se>
wrote:
>> So my code for handling all threading and deadlock issues is:
>> syncronize(this) {
>> ...
>> // do update here
>> ...
>> }
>
> What object is "this"? I am afraid that "this" is a service object and
> then you will disable all parallell access to that service.
Thats the idea yes.
> Your
> solution will disable parallell access much more than an RDBMS.
Indeed it will.
> Your
> entire transaction has to be included in a synchronize block and no
> other threads will be able to execute this block until the first thread
> has completed. A RBDMS will only lock the effected records, not your
> service.
That is indeed the point Im making - that for an in-memory model
I can just mutex access completely for all operations because allowing
multiple threads give me no advantages:
* it doesnt increase thoughput like it would in an external DBMS.
* response time are so much lower a (1-10 thousand times) that
I can afford coarse mutexing of all operations an still have say < 1ms
response times.
Ultimately multihtreading is a solution to a problem that I dont have
if my serial processing is sufficiently fast ...
Paul C.
|
|
0 |
|
paul
3/28/2005 5:31:51 PM
> Ultimately multihtreading is a solution to a problem that I dont have > if my serial processing is sufficiently fast ... If you didn't disable multithreading, your application could be faster. For many applications a RDBMS is "sufficiently fast". Many RDBMS can operate all-in-memory. There are also RDBMS like HSQLDB that can run in the same process as your application, if you want to avoid inter-process serialization. Bad algorithms could always be motivated by "it syfficiently fast anyway", but I don't understand why we need to choose a slow algorithm, if it exists a faster one? Maybe we should start using bubble-sort instead of quicksort, because your computer can do a bubble-sort < 1 ms? Fredrik Bertilsson http://butler.sourceforge.net
Hi, Uzytkownik "frebe" <fredrik_bertilsson@passagen.se> napisal w wiadomosci news:1111837037.996368.247920@f14g2000cwb.googlegroups.com... > Michal Kleczek wrote: >> you have business logic (loan.aprove()) >> and search/find logic (where id=...) mixed together. >> It can change for differnet reasons >> (i.e. pk changed) so it should be separated. > > Can you give some examples of why "business logic" and "search/find > logic" can be changed for different reasons? Do you have an example of > primary key change, where separation would have isolated the change > only to the "search/find logic" layer? Primary key change was just an example from top of my head. Personally I find this kind of separation usefull when I want to reuse so called "business logic" in online and batch applications. > > Fredrik Bertilsson > http://butler.sourceforge.net > Michal Kleczek
michal9954> Primary key change was just an example from top of my head. I am looking forward to any example of schema change that is isolated only to the "search/find logic" layer, with or without primary key change. > Personally I find this kind of separation usefull when I want to reuse > so called "business logic" in online and batch applications. Why would you not be able to resue business logic in online and batch applications if the "business" logic is not separated from the "search/find" logic??? Fredrik Bertilsson http://butler.sourceforge.net
On 28 Mar 2005 10:00:28 -0800, frebe wrote: >> Ultimately multihtreading is a solution to a problem that I dont have >> if my serial processing is sufficiently fast ... > > If you didn't disable multithreading, your application could be faster. > For many applications a RDBMS is "sufficiently fast". Many RDBMS can > operate all-in-memory. There are also RDBMS like HSQLDB that can run in > the same process as your application, if you want to avoid > inter-process serialization. > > Bad algorithms could always be motivated by "it syfficiently fast > anyway", but I don't understand why we need to choose a slow algorithm, > if it exists a faster one? Maybe we should start using bubble-sort > instead of quicksort, because your computer can do a bubble-sort < 1 > ms? Stealing your method of argumentation: Should we start to use RDBMS instead of ADT, because for many applications a RDBMS is "sufficiently fast" [<1min]? (:-)) [ If Costin agreed to post a complete solution then we could test how many users a foul linear search would serve beating his precious SQL. Something tells me that it would be MANY. ] But that's aside. What about dining philosophers in SQL? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
> Should we start to use RDBMS instead of ADT, because for many applications > a RDBMS is "sufficiently fast" [<1min]? (:-)) A RDBMS should be used when you need some of its features like: * Queries * Transactions * Caching * Concurrency control For many applications - like FTP clients, mail clients, text editors etc - you don't need any of these features. For some applications you might need some of these features, but hashtables, flat files, semaphors, monitors, etc, may do the work as well for you. And for some applications it is obvious that you need the features in an RDBMS. The decision whether to use a RDBMS can mostly be done very early in the design phase of the application. It is a question about using low-level componets vs high-level components and a question about using pre-built components vs doing the work by yourself. I don't understand your question about RDBMS vs ADT. ADT does not provide any functionality at all. It is just a way to define and implement functionality. Collection classes such as hashtables and arrays has nothing to do with ADT either. > If Costin agreed to post a complete solution then we could test how many > users a foul linear search would serve beating his precious SQL. Something > tells me that it would be MANY. A RDBMS use to do a full table scan if the number of records is less than a couple of houndreds. If think you will get the same result. But you need to use a RDBMS that runs in the same process as your test application. Fredrik Bertilsson http://butler.sourceforge.net
On 28 Mar 2005 11:51:25 -0800, frebe wrote: >> Should we start to use RDBMS instead of ADT, because for many applications >> a RDBMS is "sufficiently fast" [<1min]? (:-)) > > A RDBMS should be used when you need some of its features like: > * Queries > * Transactions > * Caching > * Concurrency control Also dining philosophers qualify? > For many applications - like FTP clients, mail clients, text editors > etc - you don't need any of these features. Actually before that Windows/UNIX disaster many text editors were caching and session-oriented. I remember DEC's EDT. It was quite handy, especial when your machine had a nasty habit to crash at the very moment you saved your file... > For some applications you > might need some of these features, but hashtables, flat files, > semaphors, monitors, etc, may do the work as well for you. And for some > applications it is obvious that you need the features in an RDBMS. The > decision whether to use a RDBMS can mostly be done very early in the > design phase of the application. It is not always evident, but often it is. > It is a question about using low-level componets vs high-level > components and a question about using pre-built components vs doing the > work by yourself. > > I don't understand your question about RDBMS vs ADT. ADT does not > provide any functionality at all. It is just a way to define and > implement functionality. If you say that there is no opposition between ADT and ADTs describing relations, I will immediately agree. But from what you write ADT always appears either low-level or slow. > Collection classes such as hashtables and > arrays has nothing to do with ADT either. They are implemented as ADTs. And because relations too can be easily implemented as ADTs there is absolutely no point in treating RDBMS as something exceptional. RDBMS is an implementation issue, no more than that. Therefore it makes a lot of sense to decouple it from the application logic. >> If Costin agreed to post a complete solution then we could test how many >> users a foul linear search would serve beating his precious SQL. Something >> tells me that it would be MANY. > > A RDBMS use to do a full table scan if the number of records is less > than a couple of houndreds. If think you will get the same result. But > you need to use a RDBMS that runs in the same process as your test > application. Where are any "advantages" of multitasking then? What kind of DoS this toy problem may suffer? Paul argued that there is no such problem, but you objected, referring something what seems a *different* problem... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
On 28 Mar 2005 10:00:28 -0800, frebe <fredrik_bertilsson@passagen.se> wrote: >> Ultimately multihtreading is a solution to a problem that I dont have >> if my serial processing is sufficiently fast ... > > If you didn't disable multithreading, your application could be faster. No it couldnt. For pure computational tasks single threaded serialisation is the fastest theoretical solution. The CPU is never idle thus there cannot be any throughput advantage to mutithreading. Remeber we have replaced an IO bound operation (DB access) with a CPU bound one (in memory model update). Paul C.
|
|
0 |
|
paul
3/28/2005 9:15:12 PM
Hi, >> Primary key change was just an example from top of my head. > > I am looking forward to any example of schema change that is isolated > only to the "search/find logic" layer, with or without primary key > change. I can think of such scenario (actually it's not imaginary). Imagine two closely related companies using the same (yet another accounting) application. Guess what happens: a merger - two databases have to be consolidated. The task is easy: the only thing to do is to add identifying relationship between departments table (new one - it wasn't needed before) and accounts table. > >> Personally I find this kind of separation usefull when I want to > reuse >> so called "business logic" in online and batch applications. > > Why would you not be able to resue business logic in online and batch > applications if the "business" logic is not separated from the > "search/find" logic??? > It would be more difficult. As an example: Every two weeks you run billing/invoicing process. You have to find customers to invoice, calculate the money each of them has to pay, then issue an invoice and send it to the customer (via email or however the customer wants). The same logic can be applied on demand to any customer the user choose. IMHO it's quite natural to separate finding customer/customers from billing/invoicing/sending logic. > Fredrik Bertilsson > http://butler.sourceforge.net > Michal
> the only thing to do is to add identifying relationship between
departments table (new
> one - it wasn't needed before) and accounts table.
This schema change could never be isolated only to the "find/search"
logic layer. When you ask for availible accounts, you have to supply a
department id, which you didn't have to do before. A lot of methods in
your "business" layer has to be changed too. Most likely your client
has do be changed also. Somewhere the user has to choose which
department that should be selected.
> Every two weeks you run billing/invoicing process.
> You have to find customers to invoice, calculate the money each of
them has
> to pay, then issue an invoice
> and send it to the customer (via email or however the customer
wants).
> The same logic can be applied on demand to any customer the user
choose.
> IMHO it's quite natural to separate finding customer/customers from
> billing/invoicing/sending logic.
I don't understand the separate finding customers from billing logic
would help. Lets have an example.
Batch version:
i = SQL.query("select * from customer").iterator();
while (i.hasNext()) {
rec = (Record) i.next();
doBilling(rec);
}
Online version:
query = new SQLQuery("select * from customer where id=?");
query.setParam(1, customerId);
rec = (Record) query.run().get(0);
doBilling(rec);
This example does not separate "find/search" logic and would still be a
good solution.
Fredrik Bertilsson
http://butler.sourceforge.net
paul campbell wrote:
> On Wed, 09 Mar 2005 13:06:10 -0800, Costin Cozianu
> <c_cozianu@hotmail.com> wrote:
>
>> it should be usable from the calling context without any fear of
>> deadlock or spurious results in a multi-threaded environment. Again,
>> persistence is not an issue -- data need not be persisted (imagine
>> you had your nvram or whatever).
>
>
> Ive been pondering the transaction/multi-threaded aspect of this issue
> and its occured to me that many of problems an RDMS needs to solve do
> to some extent arise, or at least are made significantly worse, because
> the DBMS exists as a system that lives apart from the application.
>
And many more issues are solved because RDBMS exists as a system that
lives apart from the application.
> Parallelism is one such example. The latency and load characteristics
> of an RDBMS mean that almost no useful system can be written without
> allowing some degree of parallel access. If we just serialise all access,
> we end up with a system whose capacity is severly limited by cumulative
> IO latency effects rather than by actual computational resources.
> In some cases the latency of a query evaluation may be great enough to
> compromise response requirements of other updates etc. This is one of
> the reasons why we use transactions.
>
> The characteristics of a in-memory model are completely different however.
> Here a single model operation is able to utilise 100% computational
> capacity
> with no IO latency overhead. Thus it is entirely resonable to simply
> serialise all model operations.
>
> So my code for handling all threading and deadlock issues is:
>
> syncronize(this) {
> ...
> // do update here
> ...
> }
>
> :)
>
> Paul C.
Yes, but your code would not be multi-threaded. Thus will fail the
challenge.
Your claim is that even if not multi-threaded your code could be
"faster", for some really fuzzy approximation of faster.
Did you like the Win3.1 environment ? I can assure you that if we
resurrect it from the dead, and reimplement it on 32 bits, it will be a
hell of a lot "faster" then the current real multi-threaded and secure
Win32 kernels, in the same sense that your proposed architecture is
faster than a real solution.
Sure, batch systems and cooperatively threaded systems have their
domains of applicability. If you want to argue that architects should
adopt single threaded systems architectures more widely then they have
now, well, I wish you good luck.
But my challenge required that the code be multi-threaded for real.
Hi
frebe wrote:
>>the only thing to do is to add identifying relationship between
>
> departments table (new
>
>>one - it wasn't needed before) and accounts table.
>
>
> This schema change could never be isolated only to the "find/search"
> logic layer. When you ask for availible accounts, you have to supply a
> department id, which you didn't have to do before. A lot of methods in
> your "business" layer has to be changed too. Most likely your client
> has do be changed also. Somewhere the user has to choose which
> department that should be selected.
That's true. A lot of methods have to change. But not ALL of them.
Once you've packaged them in a certain way
you have to change/test/release only PART of your application.
It can save a lot of money...
>
>
>>Every two weeks you run billing/invoicing process.
>>You have to find customers to invoice, calculate the money each of
>
> them has
>
>>to pay, then issue an invoice
>>and send it to the customer (via email or however the customer
>
> wants).
>
>>The same logic can be applied on demand to any customer the user
>
> choose.
>
>>IMHO it's quite natural to separate finding customer/customers from
>>billing/invoicing/sending logic.
>
>
> I don't understand the separate finding customers from billing logic
> would help. Lets have an example.
> Batch version:
> i = SQL.query("select * from customer").iterator();
> while (i.hasNext()) {
> rec = (Record) i.next();
> doBilling(rec);
> }
>
> Online version:
> query = new SQLQuery("select * from customer where id=?");
> query.setParam(1, customerId);
> rec = (Record) query.run().get(0);
> doBilling(rec);
>
> This example does not separate "find/search" logic and would still be a
> good solution.
But you did exactly what I had in mind.
You encapsulated business logic in doBilling() function.
>
> Fredrik Bertilsson
> http://butler.sourceforge.net
>
Michal
On 28 Mar 2005 11:08:40 -0800, "frebe" <fredrik_bertilsson@passagen.se> wrote: >> Primary key change was just an example from top of my head. > >I am looking forward to any example of schema change that is isolated >only to the "search/find logic" layer, with or without primary key >change. Such concepts don't exist in the Relational Model. Regards
> That's true. A lot of methods have to change. But not ALL of > them. You will have to change every method that have a SQL statement that includes the account table. Not only the implementation is changed, the signature of every of these methods has to be changed. That means that you have to change every call to these methods. Separation will just cause you extra work. > But you did exactly what I had in mind. > You encapsulated business logic in doBilling() function. The doBilling method will also execute SQL statements, to retrieve order data etc. My solution does not have any encapsulation of the "search/find" logic. Fredrik Bertilsson http://butler.sourceforge.net
>f you say that there is no opposition between ADT and ADTs > describing relations, I will immediately agree. Of course not. ADT can be used to model tables, records, queries etc. But you need a backend RDBMS to provide the implementation, unless you want to build a RDBMS by yourself. > And because relations too can be easily implemented as ADTs > there is absolutely no point in treating RDBMS as something > exceptional. I don't think it is easy to implement relations. Making a RDBMS is a lot of amount of work. If you talking about implementing a Table class that can be searched by primary key or by a full table scan, such implementation could be done in less than a day, but when you have only implemented a fragment of the relational model. > RDBMS is an implementation issue, no more than that. > Therefore it makes a lot of sense to decouple it from the > application Correct, you don't need a RDBMS behind a JDBC/ODBC/ADO driver. It could be something much simpler, like a flat file system. But we need to agree what kind of interface we should have between the application and the database (or persistence mechanism). I think SQL (or something similar) is the best choice for many enterprise applications. You want low-level interfaces like Map and List. That is probably the best choice for low-level applications like telecom switches and embedded control software, but for applications for logistics, production control, human resource administration, these kind of interfaces are too low-level. Fredrik Bertilsson http://butler.sourceforge.net
frebe wrote: >>That's true. A lot of methods have to change. But not ALL of >>them. > > > You will have to change every method that have a SQL statement that > includes the account table. Not only the implementation is changed, the > signature of every of these methods has to be changed. That means that > you have to change every call to these methods. Separation will just > cause you extra work. > > >>But you did exactly what I had in mind. >>You encapsulated business logic in doBilling() function. > > > The doBilling method will also execute SQL statements, to retrieve > order data etc. My solution does not have any encapsulation of the > "search/find" logic. > > Fredrik Bertilsson > http://butler.sourceforge.net > Just apply the same thinking recursivelly, put sql statements in separate functions, group functions into classes, abstract out interfaces and - there you go - brand new, pretty database access subsystem. :-) I didn't know it was that easy. I think you've been here before discussing the need of database access encapsulation with RCM. Michal
On 29 Mar 2005 03:32:55 -0800, frebe wrote: >>f you say that there is no opposition between ADT and ADTs >> describing relations, I will immediately agree. > > Of course not. ADT can be used to model tables, records, queries etc. > But you need a backend RDBMS to provide the implementation, unless you > want to build a RDBMS by yourself. Why should I if there is a reusable code? Example: you buy Windows XP to play say Splinter Cell. You are quite happy not knowing that Windows activation system probably uses a giant DB. >> And because relations too can be easily implemented as ADTs >> there is absolutely no point in treating RDBMS as something >> exceptional. > > I don't think it is easy to implement relations. Making a RDBMS is a > lot of amount of work. If you talking about implementing a Table class > that can be searched by primary key or by a full table scan, such > implementation could be done in less than a day, but when you have only > implemented a fragment of the relational model. So what? It is a black box, I don't care what it in. That's the advantage of ADT. It can hide either a RDBMS or a typing office as long as it fulfills the contract, I don't need to look into. >> RDBMS is an implementation issue, no more than that. >> Therefore it makes a lot of sense to decouple it from the >> application > > Correct, you don't need a RDBMS behind a JDBC/ODBC/ADO driver. It could > be something much simpler, like a flat file system. But we need to > agree what kind of interface we should have between the application and > the database (or persistence mechanism). We should clarify first. If you mean an interface for some reusable container library then it is one thing. If you consider the interface as a bridge between equal parties - the application and the DB - then it is another thing. As I said before I don't buy separation of application and data. So the only reason to have such protocol would be a legacy system... > I think SQL (or something > similar) is the best choice for many enterprise applications. You want > low-level interfaces like Map and List. I don't see how column, table, tuple are higher level ones. To me the issues of concurrency, invariants and constraints are quite orthogonal. Let's separate (1) queries (2) caching (3) concurrency and (4) relations. 1..3 is fully applicable to lists and maps. So what makes abstract relations higher level than abstract maps? Surely not mathematics, because there they are equivalent. Also what? > That is probably the best > choice for low-level applications like telecom switches and embedded > control software, but for applications for logistics, production > control, human resource administration, these kind of interfaces are > too low-level. The line is actually drawn between standard solutions to common primitive problems and the solutions to be found. The application domain is of much lesser importance because in practically any domain it is easy to formulate a problem which would break any given solution. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
Dmitry A. Kazakov wrote: > Example: you buy Windows XP to play say Splinter Cell. You are quite happy > > I think SQL (or something > > similar) is the best choice for many enterprise applications. You want > > low-level interfaces like Map and List. > > I don't see how column, table, tuple are higher level ones. Then you need to study RDBMS a little bit more. > To me the > issues of concurrency, invariants and constraints are quite orthogonal. > Let's separate (1) queries (2) caching (3) concurrency and (4) relations. > 1..3 is fully applicable to lists and maps. Queries is not about finding a value in a hashmap using the id, or traversing an array to find the matching object. This kind of arguments just show that you have almost no knowledge at all about databases. > So what makes abstract relations higher level than abstract maps? Buy a book about databases and do some studying. > The line is actually drawn between standard solutions to common primitive > problems and the solutions to be found. What is this supposed to mean? > The application domain is of much > lesser importance because in practically any domain it is easy to formulate > a problem which would break any given solution. Another stupid argument. You know very well that different application domains have very different characteristic. One tool can be very useful in one application domain and useless in another. Fredrik Bertilsson http://butler.sourceforge.net
On 29 Mar 2005 05:31:00 -0800, frebe wrote: > Dmitry A. Kazakov wrote: >> Example: you buy Windows XP to play say Splinter Cell. You are quite happy >>> I think SQL (or something >>> similar) is the best choice for many enterprise applications. You want >>> low-level interfaces like Map and List. >> >> I don't see how column, table, tuple are higher level ones. > > Then you need to study RDBMS a little bit more. > >> To me the >> issues of concurrency, invariants and constraints are quite orthogonal. >> Let's separate (1) queries (2) caching (3) concurrency and (4) relations. >> 1..3 is fully applicable to lists and maps. > > Queries is not about finding a value in a hashmap using the id, or > traversing an array to find the matching object. This kind of arguments > just show that you have almost no knowledge at all about databases. > >> So what makes abstract relations higher level than abstract maps? > > Buy a book about databases and do some studying. I will, but you know, I am still undecided. So far I saw neither Alfredo's SQL code for power set challenge, though I posted mine. Nor I saw your solution for dining philosophers in SQL (supposed to be an ultimate language for parallel computing. I can post a "low-level" code if you want.) To ask Costin would be trolling as he has many times explained... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
On 29 Mar 2005 03:32:55 -0800, "frebe" <fredrik_bertilsson@passagen.se> wrote: >You want >low-level interfaces like Map and List. That is probably the best >choice for low-level applications like telecom switches and embedded >control software Only until we have an object-relational application programming language. Regards
Dmitry A. Kazakov wrote:
> On 29 Mar 2005 05:31:00 -0800, frebe wrote:
>
>
>>Dmitry A. Kazakov wrote:
>>
>>>Example: you buy Windows XP to play say Splinter Cell. You are quite happy
>>>
>>>>I think SQL (or something
>>>>similar) is the best choice for many enterprise applications. You want
>>>>low-level interfaces like Map and List.
>>>
>>>I don't see how column, table, tuple are higher level ones.
>>
>>Then you need to study RDBMS a little bit more.
>>
>>
>>>To me the
>>>issues of concurrency, invariants and constraints are quite orthogonal.
>>>Let's separate (1) queries (2) caching (3) concurrency and (4) relations.
>>>1..3 is fully applicable to lists and maps.
>>
>>Queries is not about finding a value in a hashmap using the id, or
>>traversing an array to find the matching object. This kind of arguments
>>just show that you have almost no knowledge at all about databases.
>>
>>
>>>So what makes abstract relations higher level than abstract maps?
>>
>>Buy a book about databases and do some studying.
>
>
> I will, but you know, I am still undecided. So far I saw neither Alfredo's
> SQL code for power set challenge, though I posted mine. Nor I saw your
> solution for dining philosophers in SQL (supposed to be an ultimate
> language for parallel computing. I can post a "low-level" code if you
> want.) To ask Costin would be trolling as he has many times explained...
>
Of course it would be trolling big time, as you both misconstrue the
opposite's party argument ("ultimate language for parallel computing"
(sic!)), and also construct such an brain-dead non-argument.
In case you have not noticed, SQL is not Turing complete, so it won't be
able to bring peace to the world, feed the poor and heal the sick. Move on.
> put sql statements in separate functions, group
> functions into classes,
> abstract out interfaces and - there you go -
> brand new, pretty database access
> subsystem.
Lets have an example. We have a table
order(orderid, partno, customerid, quantity, orderdate)
Now my application need to find every order for a given customer. Using
my way, the call would look like this:
list = query("select * from order where customerid=?", customerid)
Your way would look something like this:
list = findOrdersByCustomer(customerid)
List findOrderByCustomer(int customerid)
{
return SQL.query("select * from order where customerid=?",
customerid);
}
Lets say we want to find every order with a given product, created this
year.
list = query("select * from order where partno=? and orderdate>?",
partno, date)
You would have to create a method like this:
findOrderByPartNoAndOrderDateLessThan(int, Date)
After a while you would have a large number of methods
findOrderByBlaBlaBlaBla.
Next we want to join the customer or the product tables in different
ways. You would have to create another set of find methods:
findOrderAndCustomerByBlaBla
findOrderAndProductByBlaBla
The number of possible combinations is almost infinite and many select
statements are just used in one single context.
Don't get me wrong. I don't say that you should not write find-methods
if exactly the same select statement is called from different parts of
your application. Personally I would create a view instead, but
find-methods are of course relevant in many scenarios. But forcing
every select statement into a find-method will cause you extra work,
and give you an application that is hard to maintain.
Another argument for not forcing select statements into find-method is
that the statement way be built dynamically from the user input. The
GUI might have a radio button group to let the user choose sort order.
Or if the user did not enter any partno, that column should be removed
from the where clause.
You can build very powerful data-aware GUI components, using this
approach. Forcing all database access into a separate subsystem, will
disable any use of data-ware GUI components.
Forcing all database access into a separate subsystem, will also
disable you from creating reports. In many applications, you let the
user (or a superuser) create a report by writing a select statement and
a formatting descriptor.
Dynamic export and import features will also be disabled using your
approach.
Fredrik Bertilsson
http://butler.sourceforge.net
Costin Cozianu <c_cozianu@hotmail.com> wrote in news:3ascj4F6bllfbU1 @individual.net: > But my challenge required that the code be multi-threaded for real. LOL. When I took Physical Chemistry in college a question on the 1st exam read : "Provide the definition of the 1st law of thermodynamics as given by the book". This was a bit tricky for me because I'd not bothered to read that chapter, having 2 semesters of thermodynamics under my belt at the time. So I did my best to explain the law, writing a full page of text. I received 4 out of 25, so I went to see the professor. I explained my situation and he quizzed me for 30 min about the 1st law. At the end he said: "Well you do understand the 1st law but I'm not going to change the grade because the question was very clear and you didn't answer it." (Perhaps I should mention that there is significant animosity between the chemistry dept and the chemical engineering dept in every university.)
|
|
0 |
|
Rich
3/30/2005 3:13:06 AM
"frebe" <fredrik_bertilsson@passagen.se> wrote in news:1112103059.992639.191640@z14g2000cwz.googlegroups.com: > Then you need to study RDBMS a little bit more. > > This kind of arguments > just show that you have almost no knowledge at all about databases. > > Buy a book about databases and do some studying. > > What is this supposed to mean? > > Another stupid argument. Dmitry, you might want to dumb it down a little; I think they really can't grasp it.
|
|
0 |
|
Rich
3/30/2005 3:26:14 AM
(* When I took Physical Chemistry in college a question on the 1st exam
read : "Provide the definition of the 1st law of thermodynamics as
given by
the book". This was a bit tricky for me because I'd not bothered to
read
that chapter, having 2 semesters of thermodynamics under my belt at the
time. So I did my best to explain the law, writing a full page of text.
I
received 4 out of 25, so I went to see the professor. I explained my
situation and he quizzed me for 30 min about the 1st law. At the end he
said: "Well you do understand the 1st law but I'm not going to change
the
grade because the question was very clear and you didn't answer it." *)
That is a good lesson for the real-world actually, especially in the
era of offshored brain power: Listen to the customer and give them what
they want even if they are wrong.
-T-
On Wed, 30 Mar 2005 03:13:06 GMT, Rich MacDonald
<rich@@clevercaboose.com> wrote:
>Costin Cozianu <c_cozianu@hotmail.com> wrote in news:3ascj4F6bllfbU1
>@individual.net:
>
>> But my challenge required that the code be multi-threaded for real.
>
>LOL. When I took Physical Chemistry in college a question on the 1st exam
>read : "Provide the definition of the 1st law of thermodynamics as given by
>the book". This was a bit tricky for me because I'd not bothered to read
>that chapter, having 2 semesters of thermodynamics under my belt at the
>time. So I did my best to explain the law, writing a full page of text. I
>received 4 out of 25, so I went to see the professor. I explained my
>situation and he quizzed me for 30 min about the 1st law. At the end he
>said: "Well you do understand the 1st law but I'm not going to change the
>grade because the question was very clear and you didn't answer it."
>(Perhaps I should mention that there is significant animosity between the
>chemistry dept and the chemical engineering dept in every university.)
Several years ago I read a wonderful article in Scientific American.
I think it was in Martin Gardner's "Mathematical Games" column. The
topic was self reference. At the end of the column he described
question he had seen on a chemistry exam. The question was phrased
like this:
"Write a question suitable for a chemistry exam, and then answer it."
The person taking the test dealt with this question by providing the
following answer:
"Write a question suitable for a chemistry exam, and then answer it."
And then, of course, to answer the question he had just posed he
wrote:
"Write a question suitable for a chemistry exam, and then answer it."
-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716
"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo
unclebob2> The CPU is never idle thus there > cannot be any throughput advantage to mutithreading. Does your server only have one CPU? Different threads could be executed on different CPU:s but sharing the same memory. > we have replaced an IO bound operation (DB access) with a > CPU bound one (in memory model update). But you may still have I/O, like network communication. Your application is useless if it not interact (do some I/O) with something. Fredrik Bertilsson http://butler.sourceforge.net
Rich MacDonald wrote: > When I took Physical Chemistry in college a question on the 1st exam > read : "Provide the definition of the 1st law of thermodynamics as given by > the book". This was a bit tricky for me because I'd not bothered to read > that chapter, having 2 semesters of thermodynamics under my belt at the > time. So I did my best to explain the law, writing a full page of text. I > received 4 out of 25, so I went to see the professor. I explained my > situation and he quizzed me for 30 min about the 1st law. At the end he > said: "Well you do understand the 1st law but I'm not going to change the > grade because the question was very clear and you didn't answer it." > (Perhaps I should mention that there is significant animosity between the > chemistry dept and the chemical engineering dept in every university.) Twenty or so years ago, an Economics professor at the University of Toronto announced to his PhD class that the final exam would be held the following week. To help his students prepare, he handed out copies of last year's exam, and also the answers to all the questions. The following week, the students were expecting to be handed out exams, and were somewhat surprised when the professor began a regular lecture. When the students pointed this out, the professor hurredly left the classroom, was gone for a short while, and returned with a stack of photocopied papers. Each paper was a photocopy of last year's exam, with the date crossed out and replaced with the current date. Now, it was an open book exam, and about half of the students were fortunate enough to have brought his previously handed out answers. One student in particular wrote out the answers exactly as in the handout. When the grades were returned, he was shocked to have only received a B. He immediately went to the professor and demanded to know why he hadn't gotten an A, as the questions were the same as on last year's exam, and his answers were the same as the professor's. The professor thought about it and responded that, yes, the questions were indeed the same, but the answers had changed. Regards, Daniel Parker
On 30 Mar 2005 09:00:53 -0800, frebe <fredrik_bertilsson@passagen.se> wrote: >> The CPU is never idle thus there >> cannot be any throughput advantage to mutithreading. > > Does your server only have one CPU? Different threads could be executed > on different CPU:s but sharing the same memory. > >> we have replaced an IO bound operation (DB access) with a >> CPU bound one (in memory model update). > > But you may still have I/O, like network communication. Your > application is useless if it not interact (do some I/O) with something. Yes but those parts are not in the scope of costins challenge - the data/behaviour model is, and in my scenario that is all in non-volatile memory of some sort (costin used the term "nvr" in his challenge post) with no need for any IO ever. In any event my solution does not help or hinder the mutithreadedness of other parts of the application any more than a DBMS. Paul C.
|
|
0 |
|
paul
3/30/2005 5:47:13 PM
Rich MacDonald wrote: > Costin Cozianu <c_cozianu@hotmail.com> wrote in news:3ascj4F6bllfbU1 > @individual.net: > > >>But my challenge required that the code be multi-threaded for real. > > > LOL. When I took Physical Chemistry in college a question on the 1st exam > read : "Provide the definition of the 1st law of thermodynamics as given by > the book". This was a bit tricky for me because I'd not bothered to read > that chapter, having 2 semesters of thermodynamics under my belt at the > time. So I did my best to explain the law, writing a full page of text. I > received 4 out of 25, so I went to see the professor. I explained my > situation and he quizzed me for 30 min about the 1st law. At the end he > said: "Well you do understand the 1st law but I'm not going to change the > grade because the question was very clear and you didn't answer it." > (Perhaps I should mention that there is significant animosity between the > chemistry dept and the chemical engineering dept in every university.) That's a stupid analogy. But hey, you can take this thread and discuss life on Mars if you like. However, it is customary to change the subject, if you will.
On 30 Mar 2005 09:21:21 -0800, Daniel Parker wrote: > Rich MacDonald wrote: > >> When I took Physical Chemistry in college a question on the 1st exam >> read : "Provide the definition of the 1st law of thermodynamics as given by >> the book". This was a bit tricky for me because I'd not bothered to read >> that chapter, having 2 semesters of thermodynamics under my belt at the >> time. So I did my best to explain the law, writing a full page of text. I >> received 4 out of 25, so I went to see the professor. I explained my >> situation and he quizzed me for 30 min about the 1st law. At the end he >> said: "Well you do understand the 1st law but I'm not going to change the >> grade because the question was very clear and you didn't answer it." >> (Perhaps I should mention that there is significant animosity between the >> chemistry dept and the chemical engineering dept in every university.) > > Twenty or so years ago, an Economics professor at the University of > Toronto announced to his PhD class that the final exam would be held > the following week. To help his students prepare, he handed out copies > of last year's exam, and also the answers to all the questions. The > following week, the students were expecting to be handed out exams, and > were somewhat surprised when the professor began a regular lecture. > When the students pointed this out, the professor hurredly left the > classroom, was gone for a short while, and returned with a stack of > photocopied papers. Each paper was a photocopy of last year's exam, > with the date crossed out and replaced with the current date. Now, it > was an open book exam, and about half of the students were fortunate > enough to have brought his previously handed out answers. One student > in particular wrote out the answers exactly as in the handout. When > the grades were returned, he was shocked to have only received a B. He > immediately went to the professor and demanded to know why he hadn't > gotten an A, as the questions were the same as on last year's exam, and > his answers were the same as the professor's. The professor thought > about it and responded that, yes, the questions were indeed the same, > but the answers had changed. That was great! (:-)) The story is not only amusing but also has a deep sense, almost biblical parable. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
"paul campbell" <paulc@.o.b.je.ct.vis.sion.co.uk> wrote in news:opsogo0zn5d1al5o@main.main: >>> The CPU is never idle thus there >>> cannot be any throughput advantage to mutithreading. >> >> Does your server only have one CPU? Different threads could be executed >> on different CPU:s but sharing the same memory. >> >>> we have replaced an IO bound operation (DB access) with a >>> CPU bound one (in memory model update). >> >> But you may still have I/O, like network communication. Your >> application is useless if it not interact (do some I/O) with something. > > Yes but those parts are not in the scope of costins challenge Not for long :-)
|
|
0 |
|
Rich
3/31/2005 5:48:26 AM
Daniel Parker wrote: > "Jeff Brooks" <jeff_brooks@nospam.com> wrote in message > news:frm%d.743889$8l.287698@pd7tw1no... > >>alex99@medcentral.com.au wrote: >> >>I wonder if the relational guys realize that a relational database can't >>be implemented without the network model because the computer architecture >>used to build software is the network model!? > > I don't think relational people care how an RDBMS is implemented, Jeff. Why > would you think they might? Because they said the network model is dead but actually the network model is in every relational database and used inside of every peice of software written. Jeff Brooks
Rich MacDonald wrote: > "Daniel Parker" <danielaparker@spam?nothanks.windupbird.com> wrote in > news:qvq%d.1338$nK.265947@news20.bellglobal.com: > > >>"Jeff Brooks" <jeff_brooks@nospam.com> wrote in message >>news:frm%d.743889$8l.287698@pd7tw1no... >> >>>alex99@medcentral.com.au wrote: >>> >>>I wonder if the relational guys realize that a relational database >>>can't be implemented without the network model because the computer >>>architecture used to build software is the network model!? >> >>I don't think relational people care how an RDBMS is implemented, >>Jeff. Why would you think they might? > > I agree with you that they don't care and I think that's very > unfortunate. It leaves them open to legitimate criticisms they can't even > understand, let alone respond to. > > IMHO, Jeff's argument is interesting because its the same one used to > blow off Topmind: "If A and B are being compared, then if A subsumes B, B > is better." No one really complains about the argument because he values > "crappy procedural", but its a different story when used to attack the > "holy relational model". That isn't what I was arguing. I think your making the assumption that is someone says A>B and someone critisizes the statement that it means the person doing the critisizing thinks A<B which isn't true. I like procedural programming. My current work right now is writting software that is better modeled using procedural so I using procedural to build it. Making any claim about something being 'better' than something else requires a way to measure 'better'. Currently we don't have a good way to do it for the procedural vs OO debate so it's is nothing more than a personal bias. Also, the relational model vs network model is the same type of thing. Everyone has their own personal bias but no one has any real proof that one is really better than the other. My debates tend to be more meta than about specific comparisons. Jeff Brooks
Daniel Parker wrote: > Rich MacDonald wrote: > >>"Daniel Parker" <danielaparker@spam?nothanks.windupbird.com> wrote in >>news:qvq%d.1338$nK.265947@news20.bellglobal.com: >> >>>I don't think relational people care how an RDBMS is implemented, >>>Jeff. Why would you think they might? >> >>I agree with you that they don't care and I think that's very >>unfortunate. It leaves them open to legitimate criticisms they can't even >>understand, let alone respond to. > > Uh huh. > > The whole point of an RDBMS is that it provides a logical entry point > to data. The physical implementation is as irrelevent as is the > physical implementation of an OO interface. Statements like The point is the relational model can't exist without the network model. People were making claims that it was but it's a false claim. > "How can OO be worse than a RDBMS when it's model is powerful enought > to build one?" -- Jeff Brooks > > are literally incomprehensible, not just to relational people, but to > anyone capable of thought. What does "worse" mean? What does > "powerful" mean? Such statements are meaningless. RDBMS > implementations are written in computer languages, and that's about all > that you can say about it. Let me get this straight. If I ask how can it be worse then I'm incapable of thought but then you say almost same thing!? A powerful model is one that is turing complete. Any turing complete model can model competing models. Jeff Brooks
Rich MacDonald wrote: > "Daniel Parker" <danielaparker@hotmail.com> wrote in > news:1111429065.834515.138200@o13g2000cwo.googlegroups.com: > > RDBMS is from Mars and OO is from Venus. Lol!
Alfredo Novoa wrote: > And an RDBMS could be implemented in a relational language. Please post a link to information about any relational language. Jeff Brooks
On 29 Mar 2005 22:30:10 -0800, "topmind" <topmind@technologist.com> wrote: >That is a good lesson for the real-world actually, especially in the >era of offshored brain power: Listen to the customer and give them what >they want even if they are wrong. > >-T- I dont agree with that statement, although I understand where you are coming from with it. If i was to walk into a coffee shop and ask for a cup of coffe I would expect to get one. If I was to ask for it to have milk and two sugars I would expect to get it. The reason is that I'm not wrong in what I am asking for. However, we have to fast food shops next to each other here - mcdonalds and burger king. When I was working near them I would often walk into one and ask for the others product. While i've been queried many times as to exactly what I want until i realize which shop i'm in, i've never yet seen one of them go next door and get the burger i've asked for. I would never give the customer something they asked for if they were wrong in asking for it. I would however do carefully what the burger vendor does for me, and educate them nicely as to what they really might be wanting. Worst case scenario, they'd go next door - but in doing that, you have educated them and provided them with the correct solution.
Jeff Brooks wrote: > > Also, the relational model vs network model is the same type of thing. > Everyone has their own personal bias but no one has any real proof that > one is really better than the other. > I'm sorry I missed that statement. When comparing DB methodologies there are ways to measure them, aren't there, depending on what's important to you? Speed? Flexibility? Disk footprint? Memory footprint? Recoverability? Ease of use? Supporting products? Price? Etc. etc. Whatever you're looking for it can be measured there. Unfortunately, I don't know how to apply the same to static v dynamic, or OO v procedural, Java v. VB, PHP v Python, Perl v travesty generators, etc.
"Jeff Brooks" <jeff_brooks@nospam.com> wrote in message news:M7W3e.891745$8l.663711@pd7tw1no... > > The point is the relational model can't exist without the network model. > People were making claims that it was but it's a false claim. > Can you justify this statement? I don't understand what it means, and I don't think you do either. It's a little like claiming that probability theory can't exist without a Las Vegas casino. Regards, Daniel Parker
|
|
0 |
|
Daniel
4/4/2005 12:45:45 PM
> The point is the relational model can't exist without the network model. > People were making claims that it was but it's a false claim. If your definition of network model is "every programming language", you are correct. A RDBMS is a software and needs a programming language to be implemented. If you are talkning about the network database model, you are wrong. Most RBDMS are implemented without using a network database. Fredrik Bertilsson http://butler.sourceforge.net
Jeff Brooks wrote: > Because they said the network model is dead but actually the network > model is in every relational database and used inside of every peice of > software written. I understand that for you is the network model == a programming language. But I what is your point? The relational model is bad because it is not a programming language useful for writing any kind of software? Fredrik Bertilsson http://butler.sourceforge.net
frebe wrote: > Jeff Brooks wrote: > > Because they said the network model is dead but actually the network > > model is in every relational database and used inside of every peice > of > > software written. > > I understand that for you is the network model == a programming > language. Interesting. How then do you interpret the claim that there is a programming language in every relational database? How would it be stored, in a blob perhaps? Maybe he means that an implementation of a relational database management system requires a programming language? Regards, Daniel Parker
> Because they said the network model is dead but actually > the network model is in every relational database and > used inside of every peice of software written. Another way of looking at it is like machine language. Machine language may be behind everything, but it is generally not used by "high level" developers, high-level being those who build domain-specific applications, especially custom-built applications. It is also true that many run-time engines (interpreters) use navigational engines behind them instead of relational ones. But I feel that this should eventually change, and probably will when the hardware performance catches up. Navigational interpreters just happen to be better understood at this point in history. And "dynamic relational" needs to be implimented and tested first. But, someday it will, I predict. I feel it would be easier to debug a relational interpreter. Relational schemas are far easier to grok and query than navigational ones. -T-
Similar Artilces:
documentation of [oo::object new] and [oo::object create] methods...
Hi Donal, The documentation of [oo::object] page does not seem to provide the syntax = and details of these two methods. It simply says "see oo::class for more de= tails". And it also asks to refer [oo::objdefine] - which is fine for furth= er configuration of the created object. However, won't [oo::object new] and [oo::object create] methods need to be = documented separately in [oo::object] page? Best Regards, nagu. On 27/10/2013 20:11, nagu wrote: > The documentation of [oo::object] page does not seem to provide the > syntax and details of these two methods. It simply says "see > oo::class for more details". And it also asks to refer > [oo::objdefine] - which is fine for further configuration of the > created object. > > However, won't [oo::object new] and [oo::object create] methods need > to be documented separately in [oo::object] page? Those are formally methods defined on the [oo::class] class, which [oo::object] is an instance of. The operations on a class object are defined in that class. Yes, [oo::class] is a subclass of [oo::object]; this is definitely a little brain-boggling if you think about it too much (the two classes are brought into being simultaneously during the initialization of TclOO). To show you exactly what I mean, check out what introspection says: % info class methods oo::class create new % info class methods oo::object destroy See? Donal ...
remove_const vs. Object.remove_const vs. Object.instance_eval { remove_const }
In order to remove a class, I have to use Object.instance_eval { remove_const } Why couldn't I just use remove_const or Object.remove_const ? On Tue, Sep 22, 2009 at 3:30 PM, jko170 <jko170@gmail.com> wrote: > In order to remove a class, I have to use Object.instance_eval > { remove_const } > > Why couldn't I just use remove_const or Object.remove_const ? Module#remove_const is private. remove_const :Foo is sent to the top-level object which is not a module. Object.remove_const :Foo fails because the method is private. Object.instance_eval {remove_const :Foo} ...
Smalltalk vs. F-Script vs. Ruby vs. Objective-C
So many options, and they all claim they are heavily based on smalltalk. My plan is to learn smalltalk first (squeak or cincom visualworks?) but then I want to build a native Mac OS X app, that is, one that is not confined to living inside a smalltalk sandbox. One that uses the native aqua gui and uses core os x technology like coreimage, openGL and quartz. Which route would you recommend? Regards Marcel Marcel, > My plan is to learn smalltalk first Great plan! > (squeak or cincom visualworks?) VW is slicker, but check the licensing/cost befor...
Global Object vs Local Object
I have read C++ Primer Third Edition by Stanley B. Lippman and Josee Lajoie. I study global object and local object. I understand that global object uses to store into data segment while local object uses to store into stack segment. I have learned that local object is little faster than global object because it is very efficient. I still do not understand why global object is slower than local object since it has the same cycle count. For example: Var1 DB 00H Var2 DB 00H Var3 DB 00H Movzx eax, byte ptr [Var1] ; 3 Cycles Movzx ebx, byte ptr [Var2] ; 3 Cycl...
RDMBS vs OO vs CO
I don't buy it http://eyeonoracle.blogs.techtarget.com/2007/09/13/the-oracle-dbms-is-a-lega cy-technology/ Tim Arnold wrote: > I don't buy it > > http://eyeonfluff.blogs.techtarget.com/2007/09/13/the-oracle-dbms-is-a-lega > cy-technology/ The article is a substance-free contrivance designed to drive web-traffic. -- Daniel A. Morgan University of Washington damorgan@x.washington.edu (replace x with u to respond) Puget Sound Oracle Users Group www.psoug.org ...
Paste vs Place vs Insert Object
Okay, which is the best situation to use which procedure? I feel I should know this, but I need a review from an expert. Thanks! Place: almost always Paste: limited circumstances If you are doing a quick-and-dirty business document for digital printing (e.g., in-house on a color laser), you can copy EMF graphics, out of PowerPoint, say, and paste them into PM. It is FAR preferable to paste them into Illustrator and change colors to CMYK, save as an EPS, and place in PM. Insert Object: almost never You MAY, if the planets are properly aligned and you are working in an old enough op...
Forms Object Groups vs Object Libraries
Hello Group. I have been reading up on Oracle Forms object groups and object libraries. Can you tell me the pros and cons of one over the other? From what I know, the object groups are nice if I wanted to have different groups for each type of application, but I like the feature where you can use smart classes if object libraries are used. I guess I am really wanting to know if smart classes can be used on the objects inside object groups that live in object libraries. Truly, Emad ...
Question about function objects vs object literals?
Hi all, I'm stuck in a situation where I need help. Any help will be highly appreciated. I've created an object, after creating the object, I'm assigning one of its functions to an event handler i.e. to onBlur event of Text-area. Problem is that when I try to access object properties from the handler function, I cannot access them in some cases and get a value of undefined. Here is the sample code that I'm trying METHOD A: --------- function TestObj(src, dest){ this.src = src; this.dest= dest; this.count = 500; } TestObj.prototype.display=function(){ //following displays ...
Non OO Code Vs. OO Code
Does anybody have any statistical evidence on what percentage of code written by developers are OO? slowhand wrote: > Does anybody have any statistical evidence on what percentage of code > written by developers are OO? That would be kinda hard to come up with, as there is no hard definition on when code is OO and when not. Cheers, Ilja Responding to Slowhand wrote: > Does anybody have any statistical evidence on what percentage of code > written by developers are OO? Embedded Systems magazine <I think> did a survey awhile back that indicated in R-T/E Java is now 1st; C++ is 2nd; and C is 3rd. I don't recall the exact numbers but these three were quite close while Basic and Assembly were significantly behind. The other languages were a pot pourri a long way behind. That suggests that for R-T/E OO development now accounts for something like 30-40% of R-T/E development. I don't recall seeing any similar comparison for IT recently. But both Capers Jones and Howard Rubin administer very large databases for software projects that would have such statistics. Alas, they charge Big Bucks for subscriptions. However, this sort of statistic is just the sort of "teaser" they might use to promote their data bases, so you might want google for their sites. [Jones has a company in Burlington, MA whose name I forget; I believe Rubin works out of City University of New York (CUNY).] [BTW, the notion of "OO code" tends...
Microsoft vs Business Objects vs Microstrategy
Hi! I need to get a ratio comparison of metadata and related object development effort for BO and Msft AS + ProClarity. In fact, I already know the average development effort of metadata and other objects in Microstatregy (I am mostly concerned with atributes, facts, metrics and reports). Can anyone give me a hint or a benchmark comparison of development effort for the equivalent Microstrategy objects I referred, for Busines Objects (XI R2) and Microsoft analysis Services + Proclarity? I'd like, if possible, to have an idea like this: Average development effort for creation of a Microstrategy attribute: x minutes Average development effort for creation of a BO "attribute": x/2 minutes (for example) Average development effort for creation of a Msft AS + Proclarity "attribute": x/10 minutes Average development effort for creation of a Microstrategy fact: y minutes Average development effort for creation of a BO "fact": y*2 minutes (for example) Average development effort for creation of a Msft AS + Proclarity "fact": y/10 minutes Average development effort for creation of a Microstrategy report: z minutes Average development effort for creation of a BO "report": z/2 minutes (for example) Average development effort for creation of a Msft AS + Proclarity "report": z/10 minutes NOTE: Average Microstrategy report: 3 attributes Vs 3 metrics Average Microstrategy metric: count di...
Object Hash vs. object Array preference
Hello, In my object I have getDirectory() method which returns 2-dimentional array (or an imitation of 2-dimentional array using two JavaScript objects with auto-handled length property - please let's us do not go into an "each dot over i" clarification discussion now - however you want to call - you call it ;-) array[0] contains records of all files in the current dir. array[1] contains records of all subs in the current dir Each records is in its turn is an array of 6 elements: file/folder name, size, type, attributes, lastModified date, lastModified time. Tking into account that someone will need to build a dialog interface over this data IMHO array structure is the most suitable ('cause of sorting issue). Or a custom object on each directory entry still would be more flexible? What would you personally prefer to get out of the functiuon for easier programming? VK wrote: > In my object I have getDirectory() method which returns 2-dimentional > array > (or an imitation of 2-dimentional array using two JavaScript objects > with auto-handled length property - please let's us do not go into an > "each dot over i" clarification discussion now - however you want to > call - you call it ;-) I can accept the term "2-dimensional array" for brevity, provided that each element has the same number of subelements. > array[0] contains records of all files in the current dir. > array[1] contains records of all su...
Objects to Audit 'VS' objects to Journal
I believe all objects can be audited via CHGOBJAUD command. What objects can be journaled. What commands can be used to add the journaling function. "Jack Kingsley" <jkingsley@wmfinance.com> wrote in message news:ce2fab65.0308130337.611f0e0a@posting.google.com... > I believe all objects can be audited via CHGOBJAUD command. What > objects can be journaled. What commands can be used to add the > journaling function. You have been able to journal physical files for a long time (STRJRNPF), but from V5R1 onwards you can also journal changes to data areas and data que...
CPU Creating Objects vs Modifying Object Properties
What is the best way to monitor CPU activity and performance? THis is more of a testing question. I have an option to do either: 1) mixedColor = new Color(r, g, b) 2) mixedColor.r = r, mixedColor.g = g, mixedColor.b = b This may happen repeatedly in an animation. My assumption is that (2) would be a lot more efficient. I just don't have a good way or testing it. Ideally a native benchmarking tool would monitor performance of the jseng in various browsers (or at least 2) Also, what about double threading for animations? Is it too much of a CPU hog to start setInterval twice for one ru...
Objective survey of PHP vs ASP.NET vs JSP?
Anyone know of objective a survey of the development time and run-time considerations of PHP vs. ASP.NET vs JSP? Most arguments for one environment appear to be more on the personal level. Thanks P.S. I guess I would like to see a test app given to three programmers with 1-2 years in their specific environment and see the time taken to create the app, the quality of code, and a stress test of code. David wrote: > I guess I would like to see a test app given to three programmers with > 1-2 years in their specific environment and see the time taken to > create the app, the q...
Bilk vs. Snit: evidence vs. evidence... a simple challenge
Ok, Bilk, you and I are clearly both having a bit of a spat. Not good for you, nor me, nor COLA. I would love to see peace. Not agreement - for that will not happen - but peace. So my suggestion: you pick the three biggest "lies" or things as you see as my most outrageous claims and ask me about them. But do not tell me what they are. I will do the same with you. We will ask the questions on a Skype call... or over a chat. Something real time. Only rules on the questions are no insults or accusations... no calling each other "psychopaths" or "liars" or whatever. Just a chance for each of us to find the three claims of the others we find to be the most absurd. Questions about claims we have made - not about each other. No personal questions. I am have full faith I can answer *any* question you ask me. I can back what I have said. I can show support. I also know you cannot. You seem to feel the same way about me. I would love to have the chance to show COLA and the world who is right: you or me. You game? I bet not... I bet you know you cannot back your claims. But I would love to be proved wrong. I am even open to you modifying the "rules" I set above. I want them to be fair to both of us. What do you say? Are you willing to "face" me and show COLA and the world how right you are? I am... because I know I am right. -- "90% of computers use Microsoft's Windows ... Macs acc...
O/R mapping vs. Object Persistance vs. OODatabase
Hi all, this is my first post here and I have just started studying OOP and OOAD. My question is about best practices in the OO world for building with ease (I know coding is NEVER, EVER, easy!) OO applications. I do understand the limits of my question in the sense that even the use of one or another practice ALWAYS very much depends on what you're working on. But what would you consider for building an application with no legacy code or data, today? An N-Tier code generator for mapping your objects to a traditional relational database such as SQLServer or Oracle. This is just a fast alternative to hand-coding. http://www.ntiergen.net/ Object persistance http://www.prevayler.org/wiki.jsp Or put your data on a OODatabase such as the followings? http://www.matisse.com/ http://www.intersystems.com/cache/ And just another question... would you consider the existing OODatabase a safe place to store your data since it's a relatively new technology? Thank You, Lorenzo "Lorenzo Bolognini" <lorenzo@mysurname.net> wrote in message news:<Baagc.4678$qP2.12089@news.indigo.ie>... Lorenzo, first of all, some of the terms you use, could use some clarification The following might help you get an overview of the field and the terms http://www.objectarchitects.de/ObjectArchitects/events/OOP2004/PersistenceOptionsOOP2004e.pdf This will also answer the question about the OO-databases. Data are "safe" in most professional database products - w...
OO Challenge
Dear Ruby Community, One day I hope to learn your trade :) But before that ... A reasonably arrogant guy came out blasting in a web-forum about how OO is crap and all that. He offered a challenge which I tried to defeat but in VB.NET Now VB.NET sucks simply because the Visual Studio IDE that comes with it is all very boring, slow, bureacratic, clunky and when you get a spark of inspiration it hangs saying "Please wait while we update your Help File" (for 20 minutes) Pure Joy-Killer His challenge is as follows: * I wont give the URL yet because I want you guys to come with the b...
For each object in object
I'm trying to do this in VO: Have tried ForEachElement( oEvalObj ) CLASS AbstractCollection:VOCOM32.AbstractCollection:ForEachElement without any luck. My code vo is working but goBeregning:BeregnRefusjon(oRegning) are generating some new objects. I can't get these objects in vo. Any suggestions? "VB code For Each objKode In objRegning.Koder If Not objKode.Gyldig Then strStatus = "Ugyldig!" ElseIf objKode.Stjernekode Then strStatus = "Stjernekode" ElseIf objKode.Aggregert Then If...
ex vs. em vs. px vs. % vs. in.
Hello All, I am looking for a for a good tutorial on font size definitions in a CSS. A URL to a good tutorial with demo/example will help. I am trying to create a CSS for DocBook XML Document, but I m unable to get a cross browser/platform compatibility. I want the documents to look fairly similar on all platforms/browsers. Here is my CSS -> http://www.xml-dev.com/blog/new.css And here are 2 plaint text documents using that CSS: http://tinyurl.com/yu3j8 http://tinyurl.com/2zwoh More documents here -> http://www.xml-dev.com/blog/#88 I was told that I should always use...
JSP vs. Struts vs. JSF vs. Swing vs. Tapestry vs. Spring vs. Rails
I am a JSP developer and am constantly feeling like I am missing the boat by not using any of the other frameworks out there. However, the couple I have looked at (JSF and Rails) don't impress me. In JSP, I keep all of my logic in Servlets/Beans and all of my presentation in the JSP file, making custom tags when I need to do some HTML that involves some logic. So Servlets and Tags are the glue to the JSPs and Beans. I don't see what is wrong with this model. The biggest advantage is its flexible. An example of my frustation with JSF (which is different than all the other complaints...
Magic vs MiNT vs Gevena vs TOS vs...
Hi all, I'm starting this thread for 2 reasons: a) I'm a bit tired of reading the same subject again and again and decided to give it a little twist, b) Personal need. So, without any further ado, my situation is this: I have a stock STE with 4 Megs of memory, in which I'll be adding a hard drive (and maybe more) in this week. Being a floppy user (Atari-wise) all these years I never thought of having any other OSes than plain old TOS, but now, since I'll be getting some more space, I thought I might as well throw in a desktop/accs/resident progs setup there as well...
SoA Vs OO
For the past decade and a half, the software industry mantra has been OO. We have heard repeatedly that an object-oriented design is more maintainable, more reusable and more resilient to changing requirements. Now suddenly the air is abuzz with Service-oriented Architecture. Object-orientation does not seem to be cool any more! When I take a closer look at SoA, it seems a lot closer to functional design than object-oriented design. When I look at services, I tend to look at them in functional terms AND NOT object terms. Whatever happened to those oft-repeated protestations that function...
object vs type
What is the difference between an object and a type? JohnCreighton_@hotmail.com wrote: > What is the difference between an object and a type? > Is this a troll? A type describes some kind of set an object might belong to (grossly simplified). An object is, well, an object. Just take a look at your favorite OO language and learn about its typing system. -- No man is good enough to govern another man without that other's consent. -- Abraham Lincoln Ulrich Hobelmann wrote: > JohnCreighton_@hotmail.com wrote: > >> What is the difference between an object and a t...
OO versus RDB
I have a proposal for when to choose between OO and RDB... Consider the following class class String { public: < various accessor methods > private: char* buffer; int size; }; This is an example of where OO shines. An instance of a string is a linear array of characters - nothing more, nothing less. To represent strings relationally would be hideous. For example (using PROLOG notation) stringCharacterAtPos(StringId, Index, Char) :- Char is the character at position Index in string StringId denotes a predicate (also called relation) that is able to simultaneously represent the contents of any number of strings. However it is woefully inefficient, and simple operations like inserting into a string require many records to be changed. Now consider this class, where OO falls over! class SalariedEmployee { public: virtual float GetPay() const { return salary; } private: String name; float salary; }; This claims that a SalariedEmployee equals the composite of a string name and float salary. Well that is a lie - a SalariedEmployee is no such thing! Actually a SalariedEmployee is a human in the real world, not a simple data structure stored in computer memory or persisted on disk. Now that is obvious and we all know that OO implicitly models real world entities all the time. Nevertheless, the above class is strictly speaking a lie and should instead be renamed something like SalariedEmployeeModel, to make it clear that it is merely a mod...
Hi Donal, The documentation of [oo::object] page does not seem to provide the syntax = and details of these two methods. It simply says "see oo::class for more de= tails". And it also asks to refer [oo::objdefine] - which is fine for furth= er configuration of the created object. However, won't [oo::object new] and [oo::object create] methods need to be = documented separately in [oo::object] page? Best Regards, nagu. On 27/10/2013 20:11, nagu wrote: > The documentation of [oo::object] page does not seem to provide the > syntax and details of these two methods. It simply says "see > oo::class for more details". And it also asks to refer > [oo::objdefine] - which is fine for further configuration of the > created object. > > However, won't [oo::object new] and [oo::object create] methods need > to be documented separately in [oo::object] page? Those are formally methods defined on the [oo::class] class, which [oo::object] is an instance of. The operations on a class object are defined in that class. Yes, [oo::class] is a subclass of [oo::object]; this is definitely a little brain-boggling if you think about it too much (the two classes are brought into being simultaneously during the initialization of TclOO). To show you exactly what I mean, check out what introspection says: % info class methods oo::class create new % info class methods oo::object destroy See? Donal ...
remove_const vs. Object.remove_const vs. Object.instance_eval { remove_const }
In order to remove a class, I have to use Object.instance_eval { remove_const } Why couldn't I just use remove_const or Object.remove_const ? On Tue, Sep 22, 2009 at 3:30 PM, jko170 <jko170@gmail.com> wrote: > In order to remove a class, I have to use Object.instance_eval > { remove_const } > > Why couldn't I just use remove_const or Object.remove_const ? Module#remove_const is private. remove_const :Foo is sent to the top-level object which is not a module. Object.remove_const :Foo fails because the method is private. Object.instance_eval {remove_const :Foo} ...
Smalltalk vs. F-Script vs. Ruby vs. Objective-C
So many options, and they all claim they are heavily based on smalltalk. My plan is to learn smalltalk first (squeak or cincom visualworks?) but then I want to build a native Mac OS X app, that is, one that is not confined to living inside a smalltalk sandbox. One that uses the native aqua gui and uses core os x technology like coreimage, openGL and quartz. Which route would you recommend? Regards Marcel Marcel, > My plan is to learn smalltalk first Great plan! > (squeak or cincom visualworks?) VW is slicker, but check the licensing/cost befor...
Global Object vs Local Object
I have read C++ Primer Third Edition by Stanley B. Lippman and Josee Lajoie. I study global object and local object. I understand that global object uses to store into data segment while local object uses to store into stack segment. I have learned that local object is little faster than global object because it is very efficient. I still do not understand why global object is slower than local object since it has the same cycle count. For example: Var1 DB 00H Var2 DB 00H Var3 DB 00H Movzx eax, byte ptr [Var1] ; 3 Cycles Movzx ebx, byte ptr [Var2] ; 3 Cycl...
RDMBS vs OO vs CO
I don't buy it http://eyeonoracle.blogs.techtarget.com/2007/09/13/the-oracle-dbms-is-a-lega cy-technology/ Tim Arnold wrote: > I don't buy it > > http://eyeonfluff.blogs.techtarget.com/2007/09/13/the-oracle-dbms-is-a-lega > cy-technology/ The article is a substance-free contrivance designed to drive web-traffic. -- Daniel A. Morgan University of Washington damorgan@x.washington.edu (replace x with u to respond) Puget Sound Oracle Users Group www.psoug.org ...
Paste vs Place vs Insert Object
Okay, which is the best situation to use which procedure? I feel I should know this, but I need a review from an expert. Thanks! Place: almost always Paste: limited circumstances If you are doing a quick-and-dirty business document for digital printing (e.g., in-house on a color laser), you can copy EMF graphics, out of PowerPoint, say, and paste them into PM. It is FAR preferable to paste them into Illustrator and change colors to CMYK, save as an EPS, and place in PM. Insert Object: almost never You MAY, if the planets are properly aligned and you are working in an old enough op...
Forms Object Groups vs Object Libraries
Hello Group. I have been reading up on Oracle Forms object groups and object libraries. Can you tell me the pros and cons of one over the other? From what I know, the object groups are nice if I wanted to have different groups for each type of application, but I like the feature where you can use smart classes if object libraries are used. I guess I am really wanting to know if smart classes can be used on the objects inside object groups that live in object libraries. Truly, Emad ...
Question about function objects vs object literals?
Hi all, I'm stuck in a situation where I need help. Any help will be highly appreciated. I've created an object, after creating the object, I'm assigning one of its functions to an event handler i.e. to onBlur event of Text-area. Problem is that when I try to access object properties from the handler function, I cannot access them in some cases and get a value of undefined. Here is the sample code that I'm trying METHOD A: --------- function TestObj(src, dest){ this.src = src; this.dest= dest; this.count = 500; } TestObj.prototype.display=function(){ //following displays ...
Non OO Code Vs. OO Code
Does anybody have any statistical evidence on what percentage of code written by developers are OO? slowhand wrote: > Does anybody have any statistical evidence on what percentage of code > written by developers are OO? That would be kinda hard to come up with, as there is no hard definition on when code is OO and when not. Cheers, Ilja Responding to Slowhand wrote: > Does anybody have any statistical evidence on what percentage of code > written by developers are OO? Embedded Systems magazine <I think> did a survey awhile back that indicated in R-T/E Java is now 1st; C++ is 2nd; and C is 3rd. I don't recall the exact numbers but these three were quite close while Basic and Assembly were significantly behind. The other languages were a pot pourri a long way behind. That suggests that for R-T/E OO development now accounts for something like 30-40% of R-T/E development. I don't recall seeing any similar comparison for IT recently. But both Capers Jones and Howard Rubin administer very large databases for software projects that would have such statistics. Alas, they charge Big Bucks for subscriptions. However, this sort of statistic is just the sort of "teaser" they might use to promote their data bases, so you might want google for their sites. [Jones has a company in Burlington, MA whose name I forget; I believe Rubin works out of City University of New York (CUNY).] [BTW, the notion of "OO code" tends...
Microsoft vs Business Objects vs Microstrategy
Hi! I need to get a ratio comparison of metadata and related object development effort for BO and Msft AS + ProClarity. In fact, I already know the average development effort of metadata and other objects in Microstatregy (I am mostly concerned with atributes, facts, metrics and reports). Can anyone give me a hint or a benchmark comparison of development effort for the equivalent Microstrategy objects I referred, for Busines Objects (XI R2) and Microsoft analysis Services + Proclarity? I'd like, if possible, to have an idea like this: Average development effort for creation of a Microstrategy attribute: x minutes Average development effort for creation of a BO "attribute": x/2 minutes (for example) Average development effort for creation of a Msft AS + Proclarity "attribute": x/10 minutes Average development effort for creation of a Microstrategy fact: y minutes Average development effort for creation of a BO "fact": y*2 minutes (for example) Average development effort for creation of a Msft AS + Proclarity "fact": y/10 minutes Average development effort for creation of a Microstrategy report: z minutes Average development effort for creation of a BO "report": z/2 minutes (for example) Average development effort for creation of a Msft AS + Proclarity "report": z/10 minutes NOTE: Average Microstrategy report: 3 attributes Vs 3 metrics Average Microstrategy metric: count di...
Object Hash vs. object Array preference
Hello, In my object I have getDirectory() method which returns 2-dimentional array (or an imitation of 2-dimentional array using two JavaScript objects with auto-handled length property - please let's us do not go into an "each dot over i" clarification discussion now - however you want to call - you call it ;-) array[0] contains records of all files in the current dir. array[1] contains records of all subs in the current dir Each records is in its turn is an array of 6 elements: file/folder name, size, type, attributes, lastModified date, lastModified time. Tking into account that someone will need to build a dialog interface over this data IMHO array structure is the most suitable ('cause of sorting issue). Or a custom object on each directory entry still would be more flexible? What would you personally prefer to get out of the functiuon for easier programming? VK wrote: > In my object I have getDirectory() method which returns 2-dimentional > array > (or an imitation of 2-dimentional array using two JavaScript objects > with auto-handled length property - please let's us do not go into an > "each dot over i" clarification discussion now - however you want to > call - you call it ;-) I can accept the term "2-dimensional array" for brevity, provided that each element has the same number of subelements. > array[0] contains records of all files in the current dir. > array[1] contains records of all su...
Objects to Audit 'VS' objects to Journal
I believe all objects can be audited via CHGOBJAUD command. What objects can be journaled. What commands can be used to add the journaling function. "Jack Kingsley" <jkingsley@wmfinance.com> wrote in message news:ce2fab65.0308130337.611f0e0a@posting.google.com... > I believe all objects can be audited via CHGOBJAUD command. What > objects can be journaled. What commands can be used to add the > journaling function. You have been able to journal physical files for a long time (STRJRNPF), but from V5R1 onwards you can also journal changes to data areas and data que...
CPU Creating Objects vs Modifying Object Properties
What is the best way to monitor CPU activity and performance? THis is more of a testing question. I have an option to do either: 1) mixedColor = new Color(r, g, b) 2) mixedColor.r = r, mixedColor.g = g, mixedColor.b = b This may happen repeatedly in an animation. My assumption is that (2) would be a lot more efficient. I just don't have a good way or testing it. Ideally a native benchmarking tool would monitor performance of the jseng in various browsers (or at least 2) Also, what about double threading for animations? Is it too much of a CPU hog to start setInterval twice for one ru...
Objective survey of PHP vs ASP.NET vs JSP?
Anyone know of objective a survey of the development time and run-time considerations of PHP vs. ASP.NET vs JSP? Most arguments for one environment appear to be more on the personal level. Thanks P.S. I guess I would like to see a test app given to three programmers with 1-2 years in their specific environment and see the time taken to create the app, the quality of code, and a stress test of code. David wrote: > I guess I would like to see a test app given to three programmers with > 1-2 years in their specific environment and see the time taken to > create the app, the q...
Bilk vs. Snit: evidence vs. evidence... a simple challenge
Ok, Bilk, you and I are clearly both having a bit of a spat. Not good for you, nor me, nor COLA. I would love to see peace. Not agreement - for that will not happen - but peace. So my suggestion: you pick the three biggest "lies" or things as you see as my most outrageous claims and ask me about them. But do not tell me what they are. I will do the same with you. We will ask the questions on a Skype call... or over a chat. Something real time. Only rules on the questions are no insults or accusations... no calling each other "psychopaths" or "liars" or whatever. Just a chance for each of us to find the three claims of the others we find to be the most absurd. Questions about claims we have made - not about each other. No personal questions. I am have full faith I can answer *any* question you ask me. I can back what I have said. I can show support. I also know you cannot. You seem to feel the same way about me. I would love to have the chance to show COLA and the world who is right: you or me. You game? I bet not... I bet you know you cannot back your claims. But I would love to be proved wrong. I am even open to you modifying the "rules" I set above. I want them to be fair to both of us. What do you say? Are you willing to "face" me and show COLA and the world how right you are? I am... because I know I am right. -- "90% of computers use Microsoft's Windows ... Macs acc...
O/R mapping vs. Object Persistance vs. OODatabase
Hi all, this is my first post here and I have just started studying OOP and OOAD. My question is about best practices in the OO world for building with ease (I know coding is NEVER, EVER, easy!) OO applications. I do understand the limits of my question in the sense that even the use of one or another practice ALWAYS very much depends on what you're working on. But what would you consider for building an application with no legacy code or data, today? An N-Tier code generator for mapping your objects to a traditional relational database such as SQLServer or Oracle. This is just a fast alternative to hand-coding. http://www.ntiergen.net/ Object persistance http://www.prevayler.org/wiki.jsp Or put your data on a OODatabase such as the followings? http://www.matisse.com/ http://www.intersystems.com/cache/ And just another question... would you consider the existing OODatabase a safe place to store your data since it's a relatively new technology? Thank You, Lorenzo "Lorenzo Bolognini" <lorenzo@mysurname.net> wrote in message news:<Baagc.4678$qP2.12089@news.indigo.ie>... Lorenzo, first of all, some of the terms you use, could use some clarification The following might help you get an overview of the field and the terms http://www.objectarchitects.de/ObjectArchitects/events/OOP2004/PersistenceOptionsOOP2004e.pdf This will also answer the question about the OO-databases. Data are "safe" in most professional database products - w...
OO Challenge
Dear Ruby Community, One day I hope to learn your trade :) But before that ... A reasonably arrogant guy came out blasting in a web-forum about how OO is crap and all that. He offered a challenge which I tried to defeat but in VB.NET Now VB.NET sucks simply because the Visual Studio IDE that comes with it is all very boring, slow, bureacratic, clunky and when you get a spark of inspiration it hangs saying "Please wait while we update your Help File" (for 20 minutes) Pure Joy-Killer His challenge is as follows: * I wont give the URL yet because I want you guys to come with the b...
For each object in object
I'm trying to do this in VO: Have tried ForEachElement( oEvalObj ) CLASS AbstractCollection:VOCOM32.AbstractCollection:ForEachElement without any luck. My code vo is working but goBeregning:BeregnRefusjon(oRegning) are generating some new objects. I can't get these objects in vo. Any suggestions? "VB code For Each objKode In objRegning.Koder If Not objKode.Gyldig Then strStatus = "Ugyldig!" ElseIf objKode.Stjernekode Then strStatus = "Stjernekode" ElseIf objKode.Aggregert Then If...
ex vs. em vs. px vs. % vs. in.
Hello All, I am looking for a for a good tutorial on font size definitions in a CSS. A URL to a good tutorial with demo/example will help. I am trying to create a CSS for DocBook XML Document, but I m unable to get a cross browser/platform compatibility. I want the documents to look fairly similar on all platforms/browsers. Here is my CSS -> http://www.xml-dev.com/blog/new.css And here are 2 plaint text documents using that CSS: http://tinyurl.com/yu3j8 http://tinyurl.com/2zwoh More documents here -> http://www.xml-dev.com/blog/#88 I was told that I should always use...
JSP vs. Struts vs. JSF vs. Swing vs. Tapestry vs. Spring vs. Rails
I am a JSP developer and am constantly feeling like I am missing the boat by not using any of the other frameworks out there. However, the couple I have looked at (JSF and Rails) don't impress me. In JSP, I keep all of my logic in Servlets/Beans and all of my presentation in the JSP file, making custom tags when I need to do some HTML that involves some logic. So Servlets and Tags are the glue to the JSPs and Beans. I don't see what is wrong with this model. The biggest advantage is its flexible. An example of my frustation with JSF (which is different than all the other complaints...
Magic vs MiNT vs Gevena vs TOS vs...
Hi all, I'm starting this thread for 2 reasons: a) I'm a bit tired of reading the same subject again and again and decided to give it a little twist, b) Personal need. So, without any further ado, my situation is this: I have a stock STE with 4 Megs of memory, in which I'll be adding a hard drive (and maybe more) in this week. Being a floppy user (Atari-wise) all these years I never thought of having any other OSes than plain old TOS, but now, since I'll be getting some more space, I thought I might as well throw in a desktop/accs/resident progs setup there as well...
SoA Vs OO
For the past decade and a half, the software industry mantra has been OO. We have heard repeatedly that an object-oriented design is more maintainable, more reusable and more resilient to changing requirements. Now suddenly the air is abuzz with Service-oriented Architecture. Object-orientation does not seem to be cool any more! When I take a closer look at SoA, it seems a lot closer to functional design than object-oriented design. When I look at services, I tend to look at them in functional terms AND NOT object terms. Whatever happened to those oft-repeated protestations that function...
object vs type
What is the difference between an object and a type? JohnCreighton_@hotmail.com wrote: > What is the difference between an object and a type? > Is this a troll? A type describes some kind of set an object might belong to (grossly simplified). An object is, well, an object. Just take a look at your favorite OO language and learn about its typing system. -- No man is good enough to govern another man without that other's consent. -- Abraham Lincoln Ulrich Hobelmann wrote: > JohnCreighton_@hotmail.com wrote: > >> What is the difference between an object and a t...
OO versus RDB
I have a proposal for when to choose between OO and RDB... Consider the following class class String { public: < various accessor methods > private: char* buffer; int size; }; This is an example of where OO shines. An instance of a string is a linear array of characters - nothing more, nothing less. To represent strings relationally would be hideous. For example (using PROLOG notation) stringCharacterAtPos(StringId, Index, Char) :- Char is the character at position Index in string StringId denotes a predicate (also called relation) that is able to simultaneously represent the contents of any number of strings. However it is woefully inefficient, and simple operations like inserting into a string require many records to be changed. Now consider this class, where OO falls over! class SalariedEmployee { public: virtual float GetPay() const { return salary; } private: String name; float salary; }; This claims that a SalariedEmployee equals the composite of a string name and float salary. Well that is a lie - a SalariedEmployee is no such thing! Actually a SalariedEmployee is a human in the real world, not a simple data structure stored in computer memory or persisted on disk. Now that is obvious and we all know that OO implicitly models real world entities all the time. Nevertheless, the above class is strictly speaking a lie and should instead be renamed something like SalariedEmployeeModel, to make it clear that it is merely a mod...
Web resources about - OO vs. RDB challenge - comp.object Challenge - Wikipedia, the free encyclopedia
Text is available under the Creative Commons Attribution-ShareAlike License ;additional terms may apply. By using this site, you agree to the ...
Text is available under the Creative Commons Attribution-ShareAlike License ;additional terms may apply. By using this site, you agree to the ...
Test cricketer Malinga Bandara out of suburban Melbourne grand final after Supreme Court challenge fails ...A Melbourne suburban cricket club were forced to make do without their star former Test cricketer in a grand final on Saturday after the Victorian ...
NAB Challenge: Brisbane v GWS Giants, Melbourne v St Kilda, West Coast v Essendon, live coverageST KILDA and Melbourne are locked in a tight battle at Etihad Stadium, with the Saints holding a slender lead at quarter-time.
Stephen Smith will challenge Labor leader Mark McGowan if party supports himFormer Federal Defence Minister Stephen Smith will lead WA Labor to the 2017 election only if he receives the support of Labor caucus members. ...
NAB Challenge: Darcy Moore rises to lift Collingwood out of the doldrumsCollingwood come from six goals down to pip the Western Bulldogs in an exciting end to pre-season.
Stephen Smith will challenge Labor leader Mark McGowan if party supports himFormer Federal Defence Minister Stephen Smith will lead WA Labor to the 2017 election only if he receives the support of Labor caucus members. ...
Stephen Smith vows to challenge for WA Labor leadership if party back himFormer federal MP Stephen Smith publicly confirms he will challenge current WA Labor leader Mark McGowan for the leadership.
Texas Western Alum Challenges SI’s Ranking of 1966 NCAA Basketball ChampionshipOn Sports Illustrated’s countdown of the “ 100 Greatest Moments in Sports History ,” the entry at #23 reads as follows : DATE : March 19, 1966 ...
7 U.S. cities picked as finalists for Smart City Challenge... under: Government/Legal , Technology The U.S. Department of Transportation was supposed to announce five finalists for its Smart Cities Challenge, ...
Samsung's big challenge with Galaxy S7
Samsung’s new Galaxy S7 and S7 Edge have gotten some favorable reviews. Do they have what it takes to beat the iPhone?
Samsung’s new Galaxy S7 and S7 Edge have gotten some favorable reviews. Do they have what it takes to beat the iPhone?
Resources last updated: 3/14/2016 2:52:40 AM