March 22, 2009 at 10:07 pm
... and, lest we take ourselves way too seriously.
__________________________________________________
Against stupidity the gods themselves contend in vain. -- Friedrich Schiller
Stop, children, what's that sound? Everybody look what's going down. -- Stephen Stills
March 23, 2009 at 5:31 am
Carlton Leach (3/22/2009)
"Cursors are only useful for people who don't know how to write SQL"
Heh... Amen Mr. Leach.
--Jeff Moden
March 23, 2009 at 4:43 pm
Jeffrey Williams (3/22/2009)
BTW - I really think Dataphor using an Intersystems Cache back-end would be an ideal application development environment. I really think you should look at it.
(In the future I will respect the suggestion by Lynn Pettis to take this discussion elsewhere.)
InterSystems Caché Technology Guide
http://www.intersystems.com/cache/technology/techguide/cache_tech-guide_01.html
"The inherent complexity of real-world data relationships doesn't fit naturally into simple rows and columns, so data is often fragmented into multiple tables that must be "joined" in order to complete even simple tasks. This results in two problems: a) queries can become very difficult to write due to the need to "join" many tables (often with complex outerjoins); and b) the processing overhead required when relational databases have to deal with complex data can be enormous.
In object technology, the complexity of the data is contained within the object, and the data is accessed by a simple consistent interface. In contrast, relational technology also provides a simple consistent interface, but because it does nothing to manage real-world data complexity the data is scattered among multiple tables the user or programmer is responsible for constantly dealing with that complexity.
Because objects can model complex data simply, object programming is the best choice for programming complex applications. Similarly, object access of the database is the best choice for inserting and updating the database (i.e., for transaction processing)."
Microsoft
The ADO.NET Entity Framework Overview
http://msdn2.microsoft.com/en-us/library/aa697427(vs.80).aspx
'While the relational model has been extremely effective in the last few decades, it's a model that targets a level of abstraction that is often not appropriate for modeling most business applications created using modern development environments.'
'Applications should be able to interact with the stores that maintain the persistent state of the system in the terms of the problem domain; specifically in the terms of a conceptual domain model, completely separated from the logical schema of the underlying store.'
'Again, the logical database schema is too fragmented, and it introduces complexity that the application doesn't need. In this example, the application is probably only interested in "sales persons" and "sales orders"; the fact that the sales persons' information is spread across 3 tables is uninteresting, but yet is knowledge that the application code has to have.
* Conceptually, we know that a sales person is associated to zero or more sales orders; however, queries need to be formulated in a way that can't leverage that knowledge; instead, this query has to do an explicit join to walk through this association.'
'An obvious question at this point would be why not just use traditional database views for this. While database views can abstract many of the mappings, often that solution won't work for several process and functional reasons: (a) many of the views are simply too complex to be generated and maintained by developers in a cost-effective way, even for some simple conceptual to logical mappings, (b) the classes of views that have the property of being automatically updatable at the store are limited, and (c) databases for core-systems in medium and large companies are used by many central and departmental applications, and having each individual application create several views in the database would pollute the database schema and create significant maintenance workload for the database administrators. In addition, database views are limited to the expressivity of the relational model, and typically lack some of the more real-world concepts of the Entity Data Model, such as inheritance and complex types.'
'The class of updatable views supported in the Entity Framework is much broader than those supported by any relational store.'
SQL Server 2008 Product Overview
http://www.microsoft.com/sql/techinfo/whitepapers/sql2008Overview.mspx
'A trend among database developers is to define high-level business objects, or entities, that they then map to the tables and columns stored in a database. Rather than programming against tables and columns in a database, developers use high-level entities such as ‘Customer’ or ‘Order’ to represent the underlying data. The ADO.NET Entity Framework enables developers to program against relational data in terms of such entities. Programming at this level of abstraction is highly productive and allows developers to take full advantage of entity-relationship modeling.'
Comparing LINQ and Its Contemporaries
by Ted Neward
http://www.usatoday.com/tech/science/mathscience/2008-01-23-fractions_N.htm?se=yahoorefer
'... the misguided belief that math education can somehow be made easy:
"Math is hard. The idea that somehow we're going to make math just fun is just a dream."'
Modeling business problem is not for any old tom, dick or harry. Relational programming is not for the faint of heart. What it is is rigorous and largely declarative and embedded in an imperative (procedural) environment. It's this 'environment' that seems to push the wrong buttons on sql experts. But the declarative part, the relational algebra they will love -:) They may even learn to appreciate the poor 'cursor'. Not for traversing rows in a table but
as a 'type'. Whatever you want to call the talent that some people have to be expert sql programmers, that 'it' can show them how to use thinking in terms of 'types' as well as sets:) Implicit conversion or relational, you can only choose one:) (You can convert an integer directly to a character but you cannot convert a list to a table without a cursor!).
I'd like to address your other question(s) in the future.
March 23, 2009 at 4:54 pm
[font="Verdana"]Interesting. I would agree that SQL is not "relational" as Codd envisaged it. I'm not sure that's necessarily such a bad thing, and to point at some failures of the technology and claim that the technology is thus invalid doesn't necessarily make it so. There are a great deal of successful applications and systems that use SQL databases.
I'm not sure I would say Microsoft are throwing out SQL or the concept of relational databases, but they are certainly exploring more in the object space within their development languages.
Have you had a look at what Oracle have done with objects within the database? I think it's a little unjust to accuse just Microsoft of this kind of thinking: it's more of an industry trend.
I still think my points on real world issues stand though as with any new technology.
[/font]
March 23, 2009 at 5:01 pm
Steve,
I was hoping you might try and get past the marketing hype and actually take a look at the product itself. One of the nice features in Intersystems Cache is the ability to code in Cache SQL, T-SQL, Basic, and other languages which get compiled to native object script.
I would think the ability to use D4 as a relational language - to build and generate relations (as far as the user is concerned) would be ideal. How it is actually implemented by the DBMS is another story.
Oh well - more discussion on that in another thread...
Jeffrey Williams
Problems are opportunities brilliantly disguised as insurmountable obstacles.
How to post questions to get better answers faster
Managing Transaction Logs
March 23, 2009 at 5:08 pm
steve dassin (3/22/2009)
Michael Valentine Jones (3/16/2009)
I read through a good bit of your blog the other day, and I have to say that the one questionit didn't seem to answer was what it could actually do for me that I can’t do now.
It seemed like the only thing it actually gave you was the ability to say you were not using SQL.
Even that is a stretch, since if my understanding of the somewhat sketchy descriptions of the
architecture is correct, it is actually layered on top of SQL.
It looks like the other readers of your blog (if there are any) were equally underwhelmed, since
virtually none of the blog entries had comments.
C'mon now. Are you sure it wouldn't be more appropriate to read the articles in braille?... and so on with miles of words containg no answer to my question...
Based in you response, then I guess that it can't really do anything for me.
March 23, 2009 at 5:13 pm
Jeffrey Williams (3/23/2009)
Steve,I was hoping you might try and get past the marketing hype and actually take a look at the product itself. One of the nice features in Intersystems Cache is the ability to code in Cache SQL, T-SQL, Basic, and other languages which get compiled to native object script.
I would think the ability to use D4 as a relational language - to build and generate relations (as far as the user is concerned) would be ideal. How it is actually implemented by the DBMS is another story.
Oh well - more discussion on that in another thread...
My understanding is that Cache does not support transactions. If so, I see that as a huge drawback. I need my ACID.
March 23, 2009 at 5:22 pm
Michael Valentine Jones (3/23/2009)[hrMy understanding is that Cache does not support transactions. If so, I see that as a huge drawback. I need my ACID.
Not true - Cache (and the underlying Mumps database engine) support full transactions with the ability to commit and rollback, the same as any SQL database.
In fact, if you are using the class objects to access the database - the class objects build in implicit transactions. When you use the SQL projection to perform an INSERT - it is all wrapped in an implicit transaction.
And, of course - you have the ability to use explicit transactions also.
Jeffrey Williams
Problems are opportunities brilliantly disguised as insurmountable obstacles.
How to post questions to get better answers faster
Managing Transaction Logs
March 24, 2009 at 6:04 pm
Michael Valentine Jones (3/23/2009)
steve dassin (3/22/2009)
Michael Valentine Jones (3/16/2009)
I read through a good bit of your blog the other day, and I have to say that the one questionit didn't seem to answer was what it could actually do for me that I can’t do now.
It seemed like the only thing it actually gave you was the ability to say you were not using SQL.
Even that is a stretch, since if my understanding of the somewhat sketchy descriptions of the
architecture is correct, it is actually layered on top of SQL.
It looks like the other readers of your blog (if there are any) were equally underwhelmed, since
virtually none of the blog entries had comments.
C'mon now. Are you sure it wouldn't be more appropriate to read the articles in braille?... and so on with miles of words containg no answer to my question...
Based in you response, then I guess that it can't really do anything for me.
I've no wish to alienate anyone who has taken the time to browse my blog. So what doya say to help me best answer your question. What are you looking for that qualifies as doing something for you. Are you an expert sql programmer and/or a developer? Sql server and dataphor are two totally different 'environments' unlike the sameness between sql server and Oracle/DB2. I tend to stress the difference in the systems but if its a specific feature your looking for so be it. Perhaps I could start a new thread with my response.
best,
steve
March 24, 2009 at 6:38 pm
Jeffrey Williams (3/23/2009)
Steve,I was hoping you might try and get past the marketing hype and actually take a look at the product itself. One of the nice features in Intersystems Cache is the ability to code in Cache SQL, T-SQL, Basic, and other languages which get compiled to native object script.
I would think the ability to use D4 as a relational language - to build and generate relations (as far as the user is concerned) would be ideal. How it is actually implemented by the DBMS is another story.
Oh well - more discussion on that in another thread...
Hello Jeff,
I suppose if Cache can handle a nested FROM clause in sql/t-sql it may be possible to write a driver. But at this time I don't think anyone in the dataphor community is interested in any additional drivers. Sql server, Oracle, DB2 and SAS seems quite enough and each offers its own pluses (and of course minuses :-)) in the form of passthru queries in their own dialect that can then be returned and manipulated as relations in dataphor (there are, of course, many other considerations). IMHO the main thrust is trying to present a picture of what dataphors intent is to developers. I hoping that sql experts will lend a hand 🙂
If you have an idea for a new specific thread that would be of real interest to you on the subject I'm all ears 🙂
best,
steve
March 25, 2009 at 8:47 am
I have heard of mumps and always regarded it as a disease.
And dataphore is a strange word.
March 25, 2009 at 3:07 pm
foxjazz (3/25/2009)
I have heard of mumps and always regarded it as a disease.And dataphore is a strange word.
Mumps is actually slang for spmum 🙂
It's data-phor as in data (for) you 🙂
>T-sql makes me squirm big time.
I have actually have sympathy for your sentiment. Feel free to start another rant (perhaps one that doesn't involve the dreaded cursor) :-).
best.
steve
March 26, 2009 at 7:12 am
I didn't realize my rant was only about cursors.
I figured that MS might be smart enough to take loop language and translate it directly to sql which it seems in some ways harder to understand. I am not particularly fond of t-sql myself.
March 26, 2009 at 8:28 am
Fox, I thought the light bulb had come on for you. When I first learned about SQL at IBM, back in about 1982, one of the main points was that it eliminated having to waste time writing loops. I can't believe you are unable to grasp the concept that SQL does the looping for you.
You have already been given quite a few examples, but I'll try a couple of simple ones for those coming late to the party.
Pseudo Code:
For X = 1 to EndOfTableA
Read Row(X) From Table A
Insert Row(X) Into Table B
EndFor
SQL:
Insert into TableB
Select * From TableA
Pseudo Code:
For X = 1 to EndOfTableA
Read Amt(X),Unit(X) From TableA
Add Amt(X) to TotalAmt
Add Units(X) to TotalUnits
EndFor
Display TotalAmt,TotalUnits
SQL:
select sum(Amt) as TotalAmt, sum(Units) as TotalUnits
From TableA
__________________________________________________
Against stupidity the gods themselves contend in vain. -- Friedrich Schiller
Stop, children, what's that sound? Everybody look what's going down. -- Stephen Stills
March 26, 2009 at 9:46 am
Bob, just because I know how to do updates (in mass) or inserts in mass to tables. Doesn't mean I favor the language of use. Don't get me wrong, I have learned a few things here in the update department, and will continue to use the stuff I learn. That doesn't mean I like some of those things.
For instance, what if I have 100k rows to insert in a table that is dependent on another table. I have to make 2 massive inserts to the tables separately, which might take longer than I wish on a live database. And instead would like to do it in chunks. Then i would code it in chunks. Look I am not saying that it's a bad thing. I am only saying I think there should be more options on how the language could be used.
All you guys have been a great help, please don't think you haven't been.
Viewing 15 posts - 376 through 390 (of 465 total)
You must be logged in to reply to this topic. Login to reply