SQL
in [OOP]
|
From: Christian Brunschen on 30 Jan 2006 09:47 In article <1138629270.801229.297510(a)g47g2000cwa.googlegroups.com>, Alfredo Novoa <alfredo_novoa(a)hotmail.com> wrote: >>>In well designed Information Systems all the business rules are >>>enforced > >>Definitely. > >>>by the DBMS. > >>not necessarily! The enforcement of business rules could happen in another >>part of the system. > >I said the well designed Information Systems ;-). If the enforcement >happens in the applications, the system is a botch-up. That is not necessarily so. If your application is the only thing that uses the data, then the application code may be the perfect place to put the business logic, because it allows the code for the entire system, from user interface to the low-level code that talks to the database, be implemented in a single, coherent fashion. And even if you have several applications all accessing the same data, you can easily separate out the logic that performs validation and enforced business rules into a separate library or framework, which all applications use; this can still be written using the same set of technologies as the applications, still allowing easier maintenance of the system, than if part of the logic of the system lives in the database and part lives in the applications. >>There may be other parts of the system >>that may be even _better_ suited to enforce data integrity, and indeed >>other business rules, than the DBMS. > >Only whether you are using a very bad DBMS. So you're sayin that even a moderately bad RDBMS is better for implementing business logic, than a very good procedural or functional or object-oriented development system that happens to use the database? I disagree completely, among other things because of the reasons I mentioned above: having as much as possible of your system developed in a coherent environment can be a huge win, when compared to a system whose logic is spread oout over vastly different parts. >> This doesn't rule out the DBMS as a >>candidate for that enforcement, but it also doesn't make it automagically >>the only possible candidate. > >DBMS were created with such a purpose. Databases were created for the purpose of storing data, and allowing access to data, in a generic way. They weren't created to necessarily assume _all_ roles in the everything that may have something to do with the data in the database, which is what you appear to be advocating. >Regards Best wishes, // Christian Brunschen
From: Alfredo Novoa on 30 Jan 2006 10:54 Christian Brunschen wote: >>Wrong, the Relational model was created for databases, persistent or >>not. >I think that you will find that the term 'database' at the time tended to >refer primarily to persistent data. Indeed, it tends to, but it does not imply persistent data. >>DBMS are for data management (business rules) and code application is >>for presentation and communication. >That is one of _several possible_ ways to partition the responsibilities, >but it is certainly _not_ the 'one true way'. In the begining of computing age there was only a way: to develop business and presentation rules in the applications. DBMS were created later to solve the problems of such a primitive approach. The history showed that it is a lot better to use specialized subsystems to manage data instead of doing everything directly in the applications, and such a specialized and reusable subsystems are called DBMS. >The _fundamental_ purpose if a database management system it to store, and >allow the retrieval and modification of, data. Very very wrong. The fundamental purpose of a DataBase Management System is to manage data. That's why it is called DBMS. Simple, isn't it? Data integrity is the most fundamental issue in database management. >As they have developed, >people have started adding more and more other functionality into database >management systems, but those are not part of the fundamental use of a >database management system. Wrong again. You are confusing what the very first database products were with what a good DBMS should be. Data integrity was very present in the mind of the first DBMS researchers. Dbase III was not a DBMS, it was a primitive file processor. >_all_ programming is about 'data management' in one way or another. >According to you, then, every computer in existance would be a 'database >management system' ? No, a DBMS must satisfy a list of requirements, but for instance most "application servers" satisfy all them. On the other hand all DBMS are application servers. >Actually, if one looks at the latest SQL standard, it does indeed look >like it defines a complete computing environment, somewhat centered around >a relational data model. Around a corruption of THE Relational Model. There is only ony Relational Model. > However, this doesn't suddenly make all other >programming environments 'obsolete' or somehow dictate that everything >that the 'database management system' _could_ do, _must_ be done in it, in >the way that you appear to suggest. Indeed, only the business rules must be implemented using the DBMS. The presentation and communication might be implemented in the applications. >>In the same way, general purpose programming languages should not be >>used for data management (business rules included) because there are >>far better tools for this called DBMS. >You're forgetting something here. The part of the RDBMS that allows you to >define arbitrary business rules _are_ 'general purpose programming >languages' which have been added to the fundamental core of relational >database management systems. It was not an addition. It is a requirement of the RM since the first day. You are probably confusing again the RM with what primitive products like DBase were able to do. A DMBS MUST allow the creation of new types and procedures, or classes if you prefer. >All you are advocating is that it should be >done under the auspices of the RDBMS, rather than within an application >that simply uses an RDBMS as a resource. RDBMS are also resources, but they are application servers intended to enforce and centralize the business rules. >No, I mean that whatever a RDBMS can do, I can write in code of my own. >That is how RDBMS:es are written, of course - in general-purpose >programming languages. This is like to say that all that a 3GL can do, you can write in assembler, but a lot worse because if you enforce the business rules in the applications then you will have to repeat the work in every application. And the abstraction level difference between Java and SQL is a lot bigger than the difference between assembler or bytecode and Java. The 3GL regressionists are very similar to the old assembler regresionists of the 80's. >Actually, no. A DBMS that focused entirely on storing data and letting you >access and modify it, can do quite well. This is not a DBMS, but a primitive file processor. > Witness the success of MySQL, Currently MySQL supports stored procedures and all the typical features of a DBMS, but in the first versions MySQL was only a primitive file processor, and an important part of its success was due to the ignorance of the application programmers. >Yet many used MySQL for the pure storage aspect, and implemented all their >business logic within the application - and successfully so. In this business any utter incompetent might be very successful. Specially in the consulting area. If you use 20 times the required resources but you solve the problem then your customer might be very satisfied. Success has little to do with efficacy in an intellectually enpoverished environment like this industry. >... only because database vendors have started adding general-purpose >programming languages to database management systems, even though they are >not fundamentally a part of the relational model. If you read Date's definition of the RM you will see that it is a fundamental part of the RM. http://www.amazon.com/gp/product/0201612941/103-9549884-4286210?v=glance&n=283155 http://www.amazon.com/gp/product/0321197844/ref=pd_sim_b_1/103-9549884-4286210?%5Fencoding=UTF8&v=glance&n=283155 >>OO languages are procedural or functional. >Um, no. If you don't know the differences between procedural, functional >and object-oriented programmign languages, I suggest you read up on them. I know the differences better than most Wal-Mart book writters. Java is an OO procedural language and Common Lisp is an OO functional and procedural language. Regards Alfredo
From: Alfredo Novoa on 30 Jan 2006 11:11 >SQL - which I beleive was backronymed as 'Structured Query Language' - >certainly _is_ a query language at its core. That's what usually happens with forced backronyms. They are not accurate. Languages don't have a core. SQL updates are as fundamental as selects. Regards
From: Christian Brunschen on 30 Jan 2006 16:18 In article <1138636452.149150.130280(a)g49g2000cwa.googlegroups.com>, Alfredo Novoa <alfredo_novoa(a)hotmail.com> wrote: >Christian Brunschen wote: > >>>Wrong, the Relational model was created for databases, persistent or >>>not. > >>I think that you will find that the term 'database' at the time tended to >>refer primarily to persistent data. > >Indeed, it tends to, but it does not imply persistent data. Something can be created _for_ a certain purpose, without being _limited_ to that purpose. >>>DBMS are for data management (business rules) and code application is >>>for presentation and communication. > >>That is one of _several possible_ ways to partition the responsibilities, >>but it is certainly _not_ the 'one true way'. > >In the begining of computing age there was only a way: to develop >business and presentation rules in the applications. DBMS were created >later to solve the problems of such a primitive approach. The history >showed that it is a lot better to use specialized subsystems to manage >data instead of doing everything directly in the applications, and such >a specialized and reusable subsystems are called DBMS. Yes, but that still doesn't suggest that _all_ _business_ logic should be in the DBMS, as you suggest. >>The _fundamental_ purpose if a database management system it to store, and >>allow the retrieval and modification of, data. > >Very very wrong. The fundamental purpose of a DataBase Management >System is to manage data. That's why it is called DBMS. Simple, isn't >it? Let me quote from C.J.Date's 'An Introduction To Database Systems, Volume 1', fifth edition, 1990, specifically section 1.2 on page 5: <quote> 1.2 WHAT IS A DATABASE SYSTEM? To repeat from section 1.1, a database system is basically a computerized record-keeping system; that is, it is a computerized system whose overall purpose is to maintain information and to make that information available on demand. </quote> >Data integrity is the most fundamental issue in database management. Data integrity is _one_ fundameental issue, but not in fact the _most_ fundamental issue: the _storage_ and _retrieval_ of the data are _even more_ fundamental - without those, there's no data whose integrity to guard. >>As they have developed, >>people have started adding more and more other functionality into database >>management systems, but those are not part of the fundamental use of a >>database management system. > >Wrong again. You are confusing what the very first database products >were with what a good DBMS should be. Data integrity was very present >in the mind of the first DBMS researchers. Integrity in the most basic sense, that no foreign key should refer to a primary key that does not exist, yes - those are the fundamental simple referential integrity points that are indeed part even of E.F.Codd's very first paper (where, however, he suggests that it may be better to perform 'consistency checking' as he calls it ona daily or evel less frequent basis, if it is known that the frequencey of operations that might put the database into an inconsistent state is small). >Dbase III was not a DBMS, it was a primitive file processor. I wasn't talking about Dbase in any version - what does that have to do with anything? >>_all_ programming is about 'data management' in one way or another. >>According to you, then, every computer in existance would be a 'database >>management system' ? > >No, a DBMS must satisfy a list of requirements, Indeed! This list is described, for instance, in thhe aforementioned book by C.J.Date, in chapter 15 - specifically, section 15.7, which described the 13 rules that are collectively known as "Codd's Twelve Rules", as well as the "nine structural, three integrity, and eighteen manipulative" features of the relational model (see pages 389 - 391). >but for instance most >"application servers" satisfy all them. On the other hand all DBMS are >application servers. None of the features required of an RDBMS according to the definition make an RDBMS, or require an RDBMS to be, an 'application server'. Therefore, your statememt 'all DBMS are application servers' is false. >>Actually, if one looks at the latest SQL standard, it does indeed look >>like it defines a complete computing environment, somewhat centered around >>a relational data model. > >Around a corruption of THE Relational Model. There is only ony >Relational Model. I was referring to the fact that most database engines available today work on something which they refer to as a 'relational model', but which is not the same as the strict and clear relational model as described by Codd. >> However, this doesn't suddenly make all other >>programming environments 'obsolete' or somehow dictate that everything >>that the 'database management system' _could_ do, _must_ be done in it, in >>the way that you appear to suggest. > >Indeed, only the business rules must be implemented using the DBMS. According to the definition in the book I referenced, there need be no support for arbitrary business logic in a RDBMS. Therefore, demanding that 'business rules must be implemented using the DBMS' is simply silly, because you can't expect a RDBMS to be able to handle arbitrary business logic. >The >presentation and communication might be implemented in the >applications. Again, that business logic that goes beyond simple data integrity, may well be better implemented _outside_ the database. Indeed it may _have_ to be, because RDBMS:es are not required to be able to support arbitrary business logic. >>>In the same way, general purpose programming languages should not be >>>used for data management (business rules included) because there are >>>far better tools for this called DBMS. > >>You're forgetting something here. The part of the RDBMS that allows you to >>define arbitrary business rules _are_ 'general purpose programming >>languages' which have been added to the fundamental core of relational >>database management systems. > >It was not an addition. It is a requirement of the RM since the first >day. Where in E.F.Codd's paper does he mention anything about the 'data bank' (to use his term) performing arbitrary business logic? The only thing mentioned (towards the very end) is simple referential integrity checking (which, as mentionned, he suggested could be done off-line, once evry day or even less frequently). >You are probably confusing again the RM with what primitive >products like DBase were able to do. Suffice it to say that you are incorrect. >A DMBS MUST allow the creation of new types and procedures, Not according to the requirements listed in 'In Introduction...'. It _does_ list a requirement, in the mind of C.J.Date rather than Codd, for the ability to create data types specifically for the purpose of defining the _domains_ of the columns, but it says nothing whatsoever about _procedures_. >or classes if you prefer. >>All you are advocating is that it should be >>done under the auspices of the RDBMS, rather than within an application >>that simply uses an RDBMS as a resource. > >RDBMS are also resources, but they are application servers Not according to Codd and Date ... >intended to enforce and centralize the business rules. intended to enforce referential and other data integrity, but not to enforce general business rules (which might go well beyond mere integrity of the data). >>No, I mean that whatever a RDBMS can do, I can write in code of my own. >>That is how RDBMS:es are written, of course - in general-purpose >>programming languages. > >This is like to say that all that a 3GL can do, you can write in >assembler, but a lot worse because if you enforce the business rules in >the applications then you will have to repeat the work in every >application. .... unless, of course, you were to do something intelligent like, say, collect the business logic in a framework orlibrary that can be used by any application, at a higher levelof abstraction than talking to the database. Or, for that matter, one could implement the business logic in a sepparate tier, which exposes a high-level protocol to client applciations, and which uses an RDBMS to store the data. >And the abstraction level difference between Java and SQL >is a lot bigger than the difference between assembler or bytecode and >Java. .... which matters how? Oneshould always work at the appropriate level of abstraction. This means, among other things, that one shouldn't go down to a lower abstraction level than necesssary; and it also means that if you are going to be reusing something on a lower abstraction level in a way that effectively expresses a higher-level abstraction, then it makes a lot of sense to wrap that up and use that higher-level abstraction. >The 3GL regressionists are very similar to the old assembler >regresionists of the 80's. >>Actually, no. A DBMS that focused entirely on storing data and letting you >>access and modify it, can do quite well. > >This is not a DBMS, but a primitive file processor. Well, according to C.J.Date and E.F.Codd, you're wrong about that. >> Witness the success of MySQL, > >Currently MySQL supports stored procedures and all the typical features >of a DBMS, but in the first versions MySQL was only a primitive file >processor, and an important part of its success was due to the >ignorance of the application programmers. MySQL, even in its early incarnations, was a relational database management system, though it was lacking in certain ways; but fundamentally, it stored data in tables, made up of rows and columns, and it used SQL to access and modify the data. True, it failed to offer ACID transactions, and alot of other things, but it did offer the fundamental data abstraction that the relational model is about. To refer to it as 'a primitive file manager' suggests that you are trying to obfuscate the issue. >>Yet many used MySQL for the pure storage aspect, and implemented all their >>business logic within the application - and successfully so. > >In this business any utter incompetent might be very successful. >Specially in the consulting area. > >If you use 20 times the required resources but you solve the problem >then your customer might be very satisfied. Success has little to do >with efficacy in an intellectually enpoverished environment like this >industry. it may be more efficient, and use less resources, to put the business logic outside the database. > >>... only because database vendors have started adding general-purpose >>programming languages to database management systems, even though they are >>not fundamentally a part of the relational model. > >If you read Date's definition of the RM you will see that it is a >fundamental part of the RM. > >http://www.amazon.com/gp/product/0201612941/103-9549884-4286210?v=glance&n=283155 >http://www.amazon.com/gp/product/0321197844/ref=pd_sim_b_1/103-9549884-4286210?%5Fencoding=UTF8&v=glance&n=283155 Rereading Date's definition ('An Introduction...', fifth edition), I do not see anything that supports the idea that putting general-purpose programming language facilities into the database management engine 'is a fundamental part of the relational model'. Quite the contrary! Would you perhaps care to offer an actual quote? I note that in the introduction to "Database in Depth: The Relational Model for Practitioners" (which is available in PDF as a sammple chapter from O'Reilly, <http://www.oreilly.com/catalog/databaseid/chapter/ch01.pdf>), C.J.Date specifically states, <quote> overall, the relational model isdeclarative, notprocedural, in nature; that is, we favor declarative solutions over procedural ones, wherever such solutions are feasible. The reason is obvious:declarative means the system does the work, means the user does the work (so we?re talking about productivity, among other things). That?s why the relational model supports declarative queries, declarative updates, declarative view definitions, declarative integrity constraints, and so on. </quote> >>>OO languages are procedural or functional. > >>Um, no. If you don't know the differences between procedural, functional >>and object-oriented programmign languages, I suggest you read up on them. > >I know the differences better than most Wal-Mart book writters. > >Java is an OO procedural language and Common Lisp is an OO functional >and procedural language. Would you care to elucidate exactly what it is you understand that terminology to _mean_ ? >Regards > Alfredo Best wishes, // Christian Brunschen
From: topmind on 30 Jan 2006 23:09
Patrick May wrote: > "topmind" <topmind(a)technologist.com> writes: > > Patrick May wrote: > > > "topmind" <topmind(a)technologist.com> writes: > > > You asked "But how are tables less close to the domain than > > > classes, methods, and attributes?" The answer is, they lack > > > behavior. The most common language for manipulating tables is SQL > > > and it is not as powerful as general purpose OO languages. > > > > How does not covering the entire behavior spectrum make it "less > > close" to the domain? > > As Mr. Lahman has eloquently pointed out, only CRUD/USER > applications map directly to the relational model. Other applications > require different models of both data and behavior. Since SQL has a > limited support for modeling behavior relative to general purpose > languages, by your own admission, it is less capable of reflecting the > abstractions of problem domains other than those of CRUD data > pipelines. To keep the discussion on track, I will generally stick to biz apps here. Most non-trivial biz apps will be helped by a RDB. I have seen very few exceptions given. > Where is your evidence that proliferation of accessors and > mutators is generally accepted as good OO practice? I have seen debates where a fair amount of participants held such view, such as usenet and c2.com. Sorry, I don't have a double-blind study or survey from Price Waterhouse auditors. Itsa side issue anyhow. Also Betrand Meyer spends a fair amount of text devoted to this subject in OOSC2 such that he talks about language features to make it easier to swap between "naked" values and accessors/muts when needed so that one did not have to pick one side or the other up-front. OOSC2 was considered a key OO work for several years. > While we're on the topic of you producing evidence for your > claims, here's a couple from this thread you still haven't supported: Most of them are informal side-issues I don't care to discuss right now. [el snippo] > > Are you saying your techniques better fit with legacy systems? > > I am saying that your claim is nonsense. Given the need to > integrate legacy systems and third party products, to expose business > functionality to a variety of other business systems, to orchestrate > various levels of processes and workflows, and meet all the other > requirements of enterprise systems, the idea that the NFRs can be met > 'by purchasing a "big-iron" RDBMS' is ridiculous. I would like a code demo on how non-RDBMS better fit legacy systems. Many RDBMS nightly-batch import info into RDBs so that it can be used more effectively than the navigational mess it came from. Buchanon (sp?) lost the navigational debate in the 70's. It's dead, Jim. > > > Experience in this newsgroup has shown that > > > attempting to educate you about software outside of your tiny box > > > is a waste of time. Hence, I simply point out when you are saying > > > more than you think you are, and move on. > > > > Perhaps because they use argument-from-authority instead of evidence > > out of bad habit. > > When you've supported some of your own claims, demonstrated a > willingness and ability to learn from people with more experience, If you want to "teach" me (or be convincing in general), show code, not brochure-talk or your personal braggings. I live in the Show Me state of mind. People who think they have all the answers are about 200 times more common than those who can publicly demonstrate it. > > You show me clear-cut coded proof, and I will change my mind. > > No, you won't. You will ignore evidence, deliberately > misunderstand clear arguments, [....] You *think* they are good arguments, but they are simply closed-to-inspection anecdotes when one takes a close look. I don't think you understand the scientific process. You think it is about votes or accolade counts. > > > > I'll type more slowly. There is no mention of ACLs in the > > > references I provided. The references I provided show how some > > > important security issues are addressed. This demonstrates that > > > your claim that '"Security" is mostly just massive ACL tables.' is > > > nonsense. > > > > Okay, I see where this went wrong. I meant security *could* be > > implemented by massive ACL tables. > > No, it cannot. Either you really don't understand this, in which > case you should not be commenting on the topic, or Mr. Lahman is > correct and you are deliberately attempting to annoy people who do > know something about the issue. > > ACLs stored in database tables don't even begin to address the > security needs of large systems. Read the references provided. All you have to do is give a realistic and fairly common example of where RDB ACL's fail. A "use case". That is how you demonstrate that "X does not work right". That is how you win debates, dude. You talk too much and show too little. I think you should re-evaluate your approach. Perhaps if it was a performance issue, then you can be excused for not giving a use-case and sample code/schemas since readers cannot test that. But performance does not seem to be your claim here. Non-performance software issues can usually be readily shown in text. > > Sincerely, > > Patrick > -T- |