SQL
in [OOP]
|
From: topmind on 29 Jan 2006 17:30 Alfredo Novoa wrote: > >One could point to Turing completeness, but clearly, it isn't a real, > >immediate loss. Completeness is rather a precondition. It does not imply > >anything. If my application area does not require something a Turing > >machine can, then I don't care. > > ANSI SQL is Turing complente, like most SQL dialects. > If true, then we are in for some nasty SQL viruses. (I don't think the TC issue really matters much. I don't expect or want to use a query language for the entire app. I use query languages for what they do best.) > > Regards -T-
From: Alfredo Novoa on 30 Jan 2006 08:41 Hi, >If true, then we are in for some nasty SQL viruses. No, because TC has nothing to do with viruses. To develop viruses we need to have access to low the level operating system API. > (I don't think the >TC issue really matters much. I don't expect or want to use a query >language for the entire app. I use query languages for what they do >best.) SQL is not only a query language, it is a database language and we should use it to enforce all data integrity and derivation rules, and sometimes we can not do that strictly declaratively, so TC is important. Regards Alfredo
From: Alfredo Novoa on 30 Jan 2006 08:47 >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? We could develop all that with a SQL compiler and the apropriate APIs. It would be perfectly possible to generate executable files from procedural SQL code. A programming language is a programming language :-) Regards
From: Alfredo Novoa on 30 Jan 2006 08:54 >>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. >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. > 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. Regards
From: Christian Brunschen on 30 Jan 2006 09:36
In article <1138628504.735894.120650(a)z14g2000cwz.googlegroups.com>, Alfredo Novoa <alfredo_novoa(a)hotmail.com> wrote: >Hi, > >>If true, then we are in for some nasty SQL viruses. > >No, because TC has nothing to do with viruses. To develop viruses we >need to have access to low the level operating system API. Not necessarily. There are viruses which spread entirely through email, exploiting flaws in email clients, and which only use high-level APIs. >> (I don't think the >>TC issue really matters much. I don't expect or want to use a query >>language for the entire app. I use query languages for what they do >>best.) > >SQL is not only a query language, it is a database language and we >should use it to enforce all data integrity and derivation rules, and >sometimes we can not do that strictly declaratively, so TC is >important. SQL - which I beleive was backronymed as 'Structured Query Language' - certainly _is_ a query language at its core. Recent versions of the SQL standard have bolted on standardized versions of previously database-vendor-specific extensions, such as stores procedures, triggers, a turing-complete extension language for those stored procedures and triggers; but none of that is part of the core of what a database does. There's a reason why all these bolt-ons have materialized: database engine vendors are unhappy with their product being seen as a storage solution, which is what it fundamentally is; so they have added these extensions in order to allow much code that doesn't have anything with the database per se, into the database engine's confines - precisely such things as stored procedures and triggers and so on. I think everybody agrees that enforcing business rules is a good thing. You, however, proclaim that this needs to be done _in the database engine_ - and then argue that in order to support this, the database engine must include its sturing-complete extensions, because otherwise you mau not be able to express all the business rules. But that's really circular reasoning: If you left all the extensions off the database engine, and used it just for its core purpose - storing data ans making available for access - all the validation can be done in code that liveds happily outside the database. So, the 'need' for turing-complete extensions to databases only arises when one starts from the premise that business logic should be implemented in the database; but that premise is one that can only be used if there exist sufficient facilities (turing-complete extensions) alongside the database's core functionality in the database engine. However, even if database engines indeed have these turing-complete extensions, this does not mean that all validation and business logic suddenly somehow _has_ to be implemented in the database: After all, the database still performs its core functionality, storage of and access to data, perfectly well, so code that uses 'just' those core parts of the database engine and performs its own validation etc, will still work. It will just do so without using those database-engine-bolt-ons. >Regards > Alfredo Best wishes, // Christian Brunschen |