SQL
in [OOP]
|
From: Christian Brunschen on 25 Jan 2006 09:25 In article <1138193090.073354.241750(a)g44g2000cwa.googlegroups.com>, Alfredo Novoa <alfredo_novoa(a)hotmail.com> wrote: >>> However, that is probably where 99.99% of the usage lies. > >>I suppose that you are talking about your usage of SQL. In an average >>enterprise application, non-persitence features like queries, >>transactions, referential integrity, caching, etc, are heavily used. > >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. >Referential integrity is only a little part of data integrity, and all >data integrity must be enforced Indeed. >by the DBMS. agai8n, same objection as above. 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. 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. >Regards Best wishes, // Christian Brunschen
From: frebe on 25 Jan 2006 09:43 >>Many RDBMS vendors supports distributed transactions (like XA). Other >>resources, such as messages may also be part of the same transaction. > But those aren't part of what the _RDBMS_ offers. Yes, it is. > You could certainly add transctions to a file system, just like they were > once added to RDBMS:es. A RDBMS such as Oracle already have support to participate in a XA transaction. A file system such as NTFS does not. You need an extra product/component to enbale NTFS to participte in a transaction. > RDBMS:es only offer transaction support _for things within their domain_ Of course. Can you name any other product offering transaction support for things not within their domain? > Was SQL then defined before COBOL was? No. In the old days COBOL program used hierachial databases such as DB/1. But a hierachial database is still more high-leven than list,maps,arrays. > Also, what is considered to be 'high' and 'low' level, can sometimes > depend a bit on your point of view. Yes, but I think we can agree that: lists,maps,array == low level tables,relations,SQL == high level >>> If you package up your data structures appropriately and offer suitable >>> operations on them, you can end up with a system that becomes similarly >>> easy to use as a database, >Presuming I was using, say, Apple's Cocoa frameworks, First you claim they you can end up with a system similary easy to use as a database, just by packaging up your data structures. Now you need an product (Cocoa) do it. Isn't Cocoa also a DBMS? > each city will have to maintain a set of all the customers that live there Sounds very similary to the obsolete network databases. Network databases and hierachial databases (XML) have been popular again in the OO subcommunity. Probably because most of the OO fans are too young to remember the reasons why they were abandoned. > It does mean, however, that you are placing your business logic no longer > in your application, but in the RDBMS. What if the difference? The RDBMS is a part of the application. Fredrik Bertilsson http://butler.sourceforge.net
From: Christian Brunschen on 25 Jan 2006 10:09 In article <1138195462.008170.121310(a)z14g2000cwz.googlegroups.com>, Alfredo Novoa <alfredo_novoa(a)hotmail.com> wrote: >Hi, > >Christian Brunschen wote: > >>The relational model, and SQL, were developed specifically for persistent >>databases. > >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. If you read Codd's original paper, available at <http://www.acm.org/classics/nov95/s1p1.html>, you will see that he refers to 'records of a file' in a number of places. While the paper is written in very general terms, it is clear that persistent 'data banks' were in the forefront of his mind. >On the other hand persistence is something relative. > >>I agree that code does some things better and DB other things, and one >>uses them *together* in a Yin-Yang fashion. They compliment each other. > >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'. >>Relational Databases and SQL are tools for the specific task of storing, >>accessing, modifying data > >And to enforce data integrity and to derive new data (calculations). The _fundamental_ purpose if a database management system it to store, and allow the retrieval and modification of, data. 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. As long as the database does its fundamental job, that of allowing access to the data, all the other things can be done within the application. These days, as saome database management systems have been extended to include languages for stored procedures and similar, a lot of that work could indeed be done in the database - but just because it _could_ doesn't necessarily mean it _should_. >> - they are single-purpose tools > >Indeed, its purpose is data management, any data management. Thats why >they are called Database Management Systems. _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' ? 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. 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. >>A 'general-purpose' programming language is >>one that allows one to write solutions to essentially arbitrary problems >>using it, possibly with some specific exceptions (such as, 'python is a >>general-purpose programming language, but due to its interpreted nature, >>it shouldn't be used for writing interrupt handlers'). > >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. 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. It _may_ make sense to put some, or all, or none of a system's business rules into the database management engine, whether as constraints, or triggers, or stored procedures. It all depends on the overall system. >>One thing to remember is that a RDBMS does _not_ do _anything_ that one >>can't do in code on one's own > >Do you mean something like to show windows controls? 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. >> - they are essentially just a pre-written >>library, with a little domain-specific language as part of its interface - >>whereas on the other hand, _most_ of the things you can fo in _code_, >>_cannot_ be done in an RDBMS. > >Nonsenses. DBMS must be extendable. Actually, no. A DBMS that focused entirely on storing data and letting you access and modify it, can do quite well. Witness the success of MySQL, which only recently has gained things like triggers and stored procedures. Yet many used MySQL for the pure storage aspect, and implemented all their business logic within the application - and successfully so. >You can do any data processing with >a DBMS .... 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. >>Procedural, funtional, object-oriented languages are all _general-purpose_ >>tools for programming computers, for writing essentially arbitrary >>programs. > >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. >> SQL _isn't_. If it were, then why do database vendors create >>languages to extend or 'hook into' the database (Oracle's PL/SQL), or > >PL/SQL is a replacement for PSM, the procedural part of ANSI SQL. ANSI >SQL is also Turing complete. Cool, there is now a _standard_ language with which the relational model has been extended - much like different database vendors have, for some time, added their own pet languages to RDBMS:es (PL/SQL in the case of Oracle). However, this doesn't change the fact that the basics of SQL - the data definition and query parts, which are the ones that have been around the longest, and are the ones that actually have something to do with the relational model - aren't turing complete, or general-purpose. Just calling an arbitrary language 'part of SQL' doesn't change the underlying relational model. >>And again, 3GL can be used to _write_ RDBMS; the converse is _not_ true. > >The converse is also true. I could write a compiler for a 3GL in ANSI >SQL or Oracle SQL .... only beacuse 'SQL' these days has been extended to encompass things vastly outside its original scope. Basically, the term 'RDBMS' has been extended and expanded over the years, until now it has become essentially a 'complete programming environment based loosely around the relational model'. This doesn't change the fact that those extensions and additions are indeed extensions and additions, and not part of the fundamental purpose of a database management system. >Regards > Alfredo Best wishes, // Christian Brunschen
From: Christian Brunschen on 25 Jan 2006 10:56 In article <1138200218.116889.72190(a)g49g2000cwa.googlegroups.com>, frebe <fredrik_bertilsson(a)passagen.se> wrote: >>>Many RDBMS vendors supports distributed transactions (like XA). Other >>>resources, such as messages may also be part of the same transaction. >> But those aren't part of what the _RDBMS_ offers. >Yes, it is. Messages aren't part of DBMS offerings, in general, are they? >> You could certainly add transctions to a file system, just like they were >> once added to RDBMS:es. >A RDBMS such as Oracle already have support to participate in a XA >transaction. A file system such as NTFS does not. You need an extra >product/component to enbale NTFS to participte in a transaction. Which in many ways isn't necessarily difficult, certainly depending on your requirements. Also, if all you need is a single transaction (i.e., no multiple participants), then even a filesystem implementation can be very straightforward. [ Also, not all RDBMS:es do offer transactions, or distributed transaction support, so those are just as bad, or good, as a filesystem is, in that respect. ] >> RDBMS:es only offer transaction support _for things within their domain_ >Of course. Can you name any other product offering transaction support >for things not within their domain? No - my point simply being that if you're not already using RDBMS:es, then their support for transactions doesn't per se help you. It may be a factor in deciding to move your data into the rdbms, though that might require you to alter your data representation. But then again, that may well be a worthwhile tradeoff. >> Was SQL then defined before COBOL was? >No. In the old days COBOL program used hierachial databases such as >DB/1. But a hierachial database is still more high-leven than >list,maps,arrays. Are you saying that COBOL programmers never used data structures of their own devising, within any application? >> Also, what is considered to be 'high' and 'low' level, can sometimes >> depend a bit on your point of view. >Yes, but I think we can agree that: >lists,maps,array == low level >tables,relations,SQL == high level In many respects, lists, maps, tables, relations, arrays, sets, SQL, files, XML are _all_ low level, depending on your point of view. >>>> If you package up your data structures appropriately and offer suitable >>>> operations on them, you can end up with a system that becomes similarly >>>> easy to use as a database, >>Presuming I was using, say, Apple's Cocoa frameworks, >First you claim they you can end up with a system similary easy to use >as a database, just by packaging up your data structures. Now you need >an product (Cocoa) do it. Isn't Cocoa also a DBMS? I don't _need_ Cocoa - Cocoa just offers me a lot of support, so that I can focus on writing the specifics of what I need. I could fairly easily write the rudiments of what is necessary as well, but since Cocoa is readily available (for other platforms than Mac OS X, you can investigate GNUStep, <http://www.gnustep.org/>), I decided to use that; and my code came out at similar complexity to yours. And no, Cocoa is not a DBMS, it's an object-oriented class library. Core Data, which is a part of Coca, can _use_ a RDBMS for storage, but isn't a DBMS itself. Note that I didn't use Core Data in my example. [ An overview of Core Data is available at <http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/> . ] >> each city will have to maintain a set of all the customers that live there >Sounds very similary to the obsolete network databases. Network >databases and hierachial databases (XML) have been popular again in the >OO subcommunity. Probably because most of the OO fans are too young to >remember the reasons why they were abandoned. Perhaps some RDBMS fans are too old to see past their preconceptions about things like network databases, when they see something that in some ways is similar but also in other, important respects is different? Basically, what I would do is to structure my data in much the same fashion as I would for a relational database - probably using Entity-Relationship modeling. However, instead of representing relationships as joins, they will be represented as direct references to the related object(s). Even in the relational model, you need to know which tables can be joined with each other, and on which columns. Using objects, all those references are already paired up for you, so to speak. You don't need to know any more about the data in my model, than you need if you model it in a relational fashion. The relational model was developed to offer a neutral, flexible, generic way to store and manage data. In some contexts, this particular genericity isn't so important, which means that bespoke solutions become more appropriate. In particular, if you have a generic, well-defined interface that lies above the level of the storage of data, then it becomes less necessary for the storage to be done in a generic fashion. For instance, if you make all your business objects available through a generic and comprehensive interface over, say, SOAP, then it becomes somewhat irrelevant whether those objects are stored in a SQL database, in flat files, in XML, or whatever. >> It does mean, however, that you are placing your business logic no longer >> in your application, but in the RDBMS. >What if the difference? The RDBMS is a part of the application. The difference comes in things like the organization of the code, the flow of control through the application, etc. >Fredrik Bertilsson >http://butler.sourceforge.net Best wishes, // Christian Brunschen
From: Oliver Wong on 25 Jan 2006 11:10
"Alfredo Novoa" <alfredo_novoa(a)hotmail.com> wrote in message news:1138192714.987538.55890(a)g43g2000cwa.googlegroups.com... > > Any program coded in a general purpose programming language might be > replicated in SQL with a similar code size, but if you want to get the > same result of a single SQL statement using a general purpose language > you might need many thousands of code lines. I highly doubt this claim, especially since "any program" is extremely general. What about the Linux kernel? Or Doom 3? What about the programs that powers my mp3 player, cellphone or digital camera? - Oliver |