March 22, 2009 at 2:46 pm
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? 🙂 . You could pull a Kon-Tiki to cross the Pacific. Or you could jump on a jet. But rather than engage in verbal vivisection I'm going to take a cue from the very able editor of this site and take a higher road (not Everest mind you but high :-).
Rather than go the 'feature route', I'm trying to paint with a broad brush. (But do note that almost every construct an sql programmer is familiar with (SELECT, WHERE, tables, keys, views, triggers, stored procedures) bears only a superficial resemblance to their relational counterpart. And lets not forget those constructs that have no counterpart in sql (a relational algebra based on closure as opposed to an sql calculus, impossibility of duplicate rows in a table, list, row and boolean types, direct addressing, constraints without limitations, multiple cascade paths, adorning of 'logical' metadata, dedicated split and concatenation of strings, dedicated relational division via table comparisons, iterative AND and OR... etcetera etcetera etcetera)).
Yes, it can be layered over most enterprise dbs. Much like Linq to SQL/Entity Framework uses sql server as relational storage. The sql db is used to persist data. But the functionality of what is referred to as DDL in sql is under the control of the dataphor server (unless specified otherwise). For DML the dataphor server uses 'chunking'. It will hand off those operations to sql server that it can do 'well', that it does efficiently to maximize performance. For those operations that sql server can't do the responsibility for the operation is taken over by the dataphor server. So it isn't unusual for each to take a percentage of lets say a SELECT statement.
As for readers being 'underwhelmed' I'd like to point out the Linq/EF (in its various flavors) has been the apple in the MS eye for over eight years. Is there substantive evidence that sql experts have studied it? Is there any evidence that the sql community has bothered to understand the 'what' and just as importantly the 'why' of it? Show me the beef here :-). I too am 'undewhelmed'. Linq/EF is, under the nose of sql experts, an attempt to bring application development into a strongly typed OO environment. It also happens to be a disavowing of the relational model for application development. So am I surprise they ignore 'me'! 🙂 Sql experts have ignored what the meaning of an 'anonymous' type is in net/Linq. It is at least a bridge to understand what the relational model (and dataphor) is all about. But make no mistake there is no one at MS, IMHO, who has any idea of what the relational model is and the evidence is the 'anonymous' type, ie. anonymous type!=a (table variable).
Many sql experts hide behind what I call a 'tired' architecture. There's the playground (backend), an oasis (frontend) and the never ending mismatch. This is simply a justification for remaining planted in the status quo. Anything that raises a question raises the question of where to do it. There is a rush to go in a circle. Where do you split a string? From the sql point of view you always have the frontend end as a crutch. For some, like Joe Celko, the frontend is the respository for everything and anything that's questionable for current sql technology. I'm simply suggesting remove two things that are by definition antagonistic toward each other (one knows variables the other doesn't!) and make it one. Similiar in concept to Linq but relational. The benifits of such an architecture and the historical problems it overcomes is what you feel is so currently underwhelming?-:) But I'm trying
to change that.
I'm not interested in doing anything with the noses of sql experts, just their heads. History has shown you can't 'teach' someone to be an sql expert. You either got 'it' or you don't. And way too few are tagged. But although sql experts don't have explicit knowledge of the relational model (ie. dataphor) the implicit ability they do have for declarative programming could benefit application developers in a relational environment. You could look at this way: circumstances make strange bedfellows 🙂
www.beyondsql.blogspot.com
March 22, 2009 at 2:52 pm
Sergiy (3/22/2009)
And believe me, mapping of SourceSystem+OriginalID to InternalID works perfectly.No service required.
[font="Verdana"]Heh. Not when you have an enterprise architect who insists that the appropriate solution is to roll out copies of the local database world-wide, and that the central system should be yet another copy.
I agree that a mapping of SourceSystem and SourceSystemID also works well -- we use that approach for generating business keys in the data warehouse here as an example. That doesn't mean it's the only approach.
[/font]
March 22, 2009 at 2:58 pm
Jeff Moden (3/22/2009)
The only reason why I'd want to write such an article is for those people who have had the mistake heaped upon them so they can at least do it without a bazillion deadlocks showing up. That's what happened to me...
[font="Verdana"]Bingo![/font]
March 22, 2009 at 5:55 pm
Bruce W Cassidy (3/22/2009)
Sergiy (3/22/2009)
And believe me, mapping of SourceSystem+OriginalID to InternalID works perfectly.No service required.
[font="Verdana"]Heh. Not when you have an enterprise architect who insists that the appropriate solution is to roll out copies of the local database world-wide, and that the central system should be yet another copy.
I agree that a mapping of SourceSystem and SourceSystemID also works well -- we use that approach for generating business keys in the data warehouse here as an example. That doesn't mean it's the only approach.
[/font]
Of course it does not.
I've seen heaps of "different" approaches, but still not any one better.
In your case the choice is driven not by the reasons related to system architecture. This fact alone should indicate that the solution must be not the best one.
If you try to compare both solutions you'll see which one is better.
Fortunately, I earned the right to make architetural decisions, so I'm gonna stick to the best one I'm aware of.
_____________
Code for TallyGenerator
March 22, 2009 at 6:09 pm
Steve Jones - Editor (3/15/2009)
...C#, VB, etc. are programming languages designed for working with a variables, of sets of variables in objects.
How do you realize a result of a query in a programming language designed for working with varibles? This is the question MS asked back around 2000. And it's the same question the architects of dataphor asked around the same time. It's only common sense the answer is a 'variable'. The fundamental difference between what MS is doing and dataphor is the 'nature' of the variable representation. Dataphor does work with sets, Linq with collections. Linq represent(s)(ed) an opportunity for sql experts to see a transition path from a 'resultset' (and the absence of a variable representation) to something the compiler understands as something native (although it's not a 'relation' in the RM sense). Unfortunately this is an abstract idea to most and dataphor represents a way to see it, feel it and taste it:-).
While C# can work with data in a database, or SQL could produce some level of a UI, I'm not sure that youwould be served by doing that."
"SQL is a server side language, or specifically working with data in an RDBMS. It seems you want the IDE to do the work of producing SQL for you using client side code. You could do that with LINQ, and I'm torn on this being a good thing. It's good that developers become more productive, and LINQ is probably better than having you write cursors. However, that doesn't mean it's better overall.
The idea of a UI integrated to a high degree with a logical model defined within the db is an important aspect of RAD. The level of integration in dataphor doesn't exist anywhere else. The fact that a relational expression, a view or a simple table can be 'derived' by the UI is always an abstract concept that you have to sink your teeth into. Unfortunately too many
users envision Access with this idea. Something so rudimentary is not something I'm taking about -:)
SQL is flawed, and while I don't agree with Steve Dassin, I think it works very well when someone learns about it and applies an honest effort to learn it.
I'm not saying sql is flawed. I'm saying sql is flawed when it comes to application development. Isn't MS leveraging the idea that foxjazz expresses about wanting to develop in his programming language of choice with Linq/EF? The fact there's a contest going on about the best (performant) way to concatenate strings in sql is harmless. The fact that it's 2009 makes it scary:-). Since sqls inception in System-R and Oracle in the 1980's there's never been the 'vision thing' for it. This has been Michael Stonebrakers point (for his own selfish reasons), sql programmers have always been satisfied with a single 'thing' to manipulate (a table). Jim Gray
became a 'hero' at MS not so much for his work on transactions and concurrency but for his public announcement that sql was no longer viable for application development. Why has the sql community been so forceful in maintaining the status quo, in not moving on? A comfort zone to end all comfort zones -:) The fact it provides endless adventure and satisfaction for experts to be cerebral where elsewhere the same problem is a nobrainer. cannot be denied. One wonders if it isn't the joy of the toy that's being passed on to new developers instead of the underwhelming nature of an obtuse solution.
March 22, 2009 at 7:15 pm
steve dassin (3/22/2009)
I'm not saying sql is flawed. I'm saying sql is flawed when it comes to application development.
[font="Verdana"]I guess I am slightly lost on what the difference is. Are you saying so long as we don't try to use SQL, it's fine?[/font]
steve dassin (3/22/2009)
Why has the sql community been so forceful in maintaining the status quo, in not moving on? A comfort zone to end all comfort zones -:) The fact it provides endless adventure and satisfaction for experts to be cerebral where elsewhere the same problem is a nobrainer. cannot be denied. One wonders if it isn't the joy of the toy that's being passed on to new developers instead of the underwhelming nature of an obtuse solution.
[font="Verdana"]Several factors in play here.
The first is pragmatism. Most businesses are not willing to bet their system architecture on an "unproven architecture". Why do new operating systems have such a long uptake time? Why is IE 6 so prevalent? Why has Linux not killed Windows in the server space? Because businesses have a lot of invested knowledge and experience in particular products, and until they see the value of moving, they won't. Return on investment, budgets, etc.
The next is... well, shall we say that the "dominant platform" has a market all of its own. Why do people still program in VB and C#, when they could use languages like Ruby? Because if a business decides to move to Ruby as their development platform, they have to be able to find trained/skilled resources in that language. Or they have to accept that they will have to retrain any new staff, making the time to replace staff losses even longer. By going with the "dominant platform", they can at least have some comfort that it's possible to find resources with the right kind of experience and skill.
Then there's just plain obstinancy. The COBOLs of the world. Why do we still use that language? Because there's so much code written in it. And yes, there's a certain amount of "comfort zone" associated with that too.
Finally, there are all of the real world issues associated with moving to some new architecture, particularly with something so fundamental as a database platform. What's the support like? What's the performance like? What's the scalability like? What's the integration like? What's the toolset like? What's the real world adoption like? Is this really the platform of the future, or are we just being regaled by pie-in-the-sky fantasies?
So while there may well be part of the issue that is the "joy of the toy", there's far more to it than that. This is not unique to SQL.
[/font]
March 22, 2009 at 7:30 pm
steve dassin (3/22/2009)
--------------------------------------------------------------------------------
I'm not saying sql is flawed. I'm saying sql is flawed when it comes to application development.
I hear this from lots of people and I ask them the same thing I am asking you. Why would you ever think that SQL (the language) should be used for application development?
SQL was not designed for application development. It was designed as a data manipulation language. It works very well with data - especially sets of data because that is how the language was designed.
If you really want a language that is both application development and database - take the recommendation earlier in this thread concerning Intersystems Cache. The system uses Mumps as it's underlying language which was designed as an OS, a database and an application development language.
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.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
March 22, 2009 at 8:56 pm
steve dassin (3/22/2009)
Steve Jones - Editor (3/15/2009)
...C#, VB, etc. are programming languages designed for working with a variables, of sets of variables in objects.How do you realize a result of a query in a programming language designed for working with varibles? This is the question MS asked back around 2000. And it's the same question the architects of dataphor asked around the same time. It's only common sense the answer is a 'variable'. The fundamental difference between what MS is doing and dataphor is the 'nature' of the variable representation. Dataphor does work with sets, Linq with collections. Linq represent(s)(ed) an opportunity for sql experts to see a transition path from a 'resultset' (and the absence of a variable representation) to something the compiler understands as something native (although it's not a 'relation' in the RM sense). Unfortunately this is an abstract idea to most and dataphor represents a way to see it, feel it and taste it:-).
While C# can work with data in a database, or SQL could produce some level of a UI, I'm not sure that youwould be served by doing that."
"SQL is a server side language, or specifically working with data in an RDBMS. It seems you want the IDE to do the work of producing SQL for you using client side code. You could do that with LINQ, and I'm torn on this being a good thing. It's good that developers become more productive, and LINQ is probably better than having you write cursors. However, that doesn't mean it's better overall.
The idea of a UI integrated to a high degree with a logical model defined within the db is an important aspect of RAD. The level of integration in dataphor doesn't exist anywhere else. The fact that a relational expression, a view or a simple table can be 'derived' by the UI is always an abstract concept that you have to sink your teeth into. Unfortunately too many
users envision Access with this idea. Something so rudimentary is not something I'm taking about -:)
SQL is flawed, and while I don't agree with Steve Dassin, I think it works very well when someone learns about it and applies an honest effort to learn it.
I'm not saying sql is flawed. I'm saying sql is flawed when it comes to application development. Isn't MS leveraging the idea that foxjazz expresses about wanting to develop in his programming language of choice with Linq/EF? The fact there's a contest going on about the best (performant) way to concatenate strings in sql is harmless. The fact that it's 2009 makes it scary:-). Since sqls inception in System-R and Oracle in the 1980's there's never been the 'vision thing' for it. This has been Michael Stonebrakers point (for his own selfish reasons), sql programmers have always been satisfied with a single 'thing' to manipulate (a table). Jim Gray
became a 'hero' at MS not so much for his work on transactions and concurrency but for his public announcement that sql was no longer viable for application development. Why has the sql community been so forceful in maintaining the status quo, in not moving on? A comfort zone to end all comfort zones -:) The fact it provides endless adventure and satisfaction for experts to be cerebral where elsewhere the same problem is a nobrainer. cannot be denied. One wonders if it isn't the joy of the toy that's being passed on to new developers instead of the underwhelming nature of an obtuse solution.
You know, instead of hijacking this thread into a discuss of Dataphor, why not take Steve's suggestion and start a separate thread to discuss Dataphor. That would be the right thing to do. You even seemed to agree:
steve dassin (3/19/2009)
Steve Jones - Editor (3/17/2009)
Steve Dassin,I haven't complained about the advertising of your product because it's free, and because you've only mentioned it in places where you appear to believe it fits the conversation. you're welcome to start a thread somewhere and debate it.
Thank you. Your courtesy and judgment are appreciated.
March 22, 2009 at 9:14 pm
Don't hijack it like you guys did with the "increment" discussion, Lynn? 😉
__________________________________________________
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 22, 2009 at 9:21 pm
[font="Verdana"]Well... didn't this thread start as a rant about the (percieved) inadequacies of the T-SQL language? In which case, discussing alternatives to the way SQL does things (as a language) isn't exactly a hi-jack.
Yes, the inadequacies being ranted about were entirely misconceptions. That doesn't mean that SQL doesn't in fact have inadequacies, or that there aren't viable alternatives.
So I'm in two minds about the hi-hack thing. But maybe starting an alternative thread to discuss SQL as a language is the best idea.
[/font]
March 22, 2009 at 9:42 pm
Bob Hovious (3/22/2009)
Don't hijack it like you guys did with the "increment" discussion, Lynn? 😉
I agree. In fact I think I may have even said that it too should be a separate thread of discussion. And now it appears that Jeff and I may being writing a joint article on the subject. That two should be a separate thread, don't think? 😉
March 22, 2009 at 9:49 pm
I just think a discussion of Dataphor should be separate and distinct from this rant which did start as a discussion regarding the shortcomings of T-SQL, but really were more about the inappropriate use of cursors to adequately complete work that was better done using set based code.
In the course of this thread we actually succeeded in passing on valuable knowledge to an individual. It would be nice if that is how we leave this thread. With that, I think I will move any further discussion regarding the NextID issue to either a PM with Jeff as we discuss the idea of a joint article, or perhaps we just start a new thread for the discussion.
March 22, 2009 at 9:53 pm
"Cursors are only useful for people who don't know how to write SQL"
March 22, 2009 at 9:55 pm
s
March 22, 2009 at 10:02 pm
Jeff Moden (3/13/2009)
foxjazz (3/13/2009)
Why couldn't they write t-sql more like C# or have a flavored compiler for t-sql so that we could work it like c# or vb depending on how you like it. (or the t-sql language which really is the worst language MS has ever put on the block). I really don't understand why the sql server group didn't do a better job of it, or is it because they were taking thier queue from ORACLE.Really stupid paradigm if you ask me, and I think it needs to be improved upon.
Heh... because the people that wrote it understood that most procedural programers shouldn't go anywhere near a database. 😉
Amen Mr Moden. You didn't just hit the nail on the head: you smashed it all the way through the fence
Viewing 15 posts - 361 through 375 (of 465 total)
You must be logged in to reply to this topic. Login to reply