"It requires you to do a lot of things manually that could easily be done automatically, and you still write bits of SQL in your code."
Which type of things can be done automatically, you see? Also, what is so bad about writing SQL queries *for complex queries*? I know in my case, I will not be hopping from database system to database system to worry about SQL compatibility issues.
"Also, more importantly, it doesn't provide an application layer that entirely abstracts the functionality from the interface. This is bad for any number of reasons."
You mean its use of ERb?
"Finally, it's pretty much tied to MySQL, so if you use PgSQL or Oracle (and you should), then you're in for a big headache."
In many cases, I think a simpler (as in more orthogonal) query language can make life a little easier than with SQL. Otherwise I agree with what you say. SQL or not, it's not imperative programming, but playing with sets. Some don't want to see it that way.
For what it's worth, saying something in SQL than saying it with imperative code is much better, I think, given its descriptive properties.
a. Why is it not possible for the relational model to manage data of arbitrary complexity? Current implementations probably can, probably can't, but that says nothing about the model itself.
b. If you can show that natural language research has reached us to a point where it can be used in production systems, then your argument is worthy about asking questions without the encoding process from question to database query. Until then, I would like to rely on the explicitness and preciseness of a query language, despite the fact that I have to "encode" my question into a query language (it seems like this is done all the time in programming, anyway.)
c. You are asserting something based on something I know nothing about (hospital systems). I don't know how you can really even assert your point about the weaknesses of the relational model without first giving me a explanation of the domain that you are using as an example. Even then, the domain could be open to subjectivity in terms of implementation options.
Hey, use what you want. For me, I enjoy the generality and simplicity that the relational model provides. Making it easier without SQL (which I originally was saying) will make it better, I believe.
I see the future now and it will happen in two phases: getting rid of SQL and then replacing it with something half-way decent (like a properly implemented relational algebra.)
That is, unless you are incensed that nothing is ever going to happen in that area of life. When you are faced with it, you'll always look the other way. But believe me, it's not that bad, especially when you don't feel the weight of judgement on you for not partcipating in this venture.
Re:From relevancy to troll and back. Whitespace
on
Python 2.3 Final Released
·
· Score: 2, Informative
I really don't understand the problem here, and why people must cavil over a non-issue like required whitespace. If you don't like it, don't use it. End of story.
Slashdot Mirror
"It requires you to do a lot of things manually that could easily be done automatically, and you still write bits of SQL in your code."
Which type of things can be done automatically, you see? Also, what is so bad about writing SQL queries *for complex queries*? I know in my case, I will not be hopping from database system to database system to worry about SQL compatibility issues.
"Also, more importantly, it doesn't provide an application layer that entirely abstracts the functionality from the interface. This is bad for any number of reasons."
You mean its use of ERb?
"Finally, it's pretty much tied to MySQL, so if you use PgSQL or Oracle (and you should), then you're in for a big headache."
I have no problem using it with PostgreSQL.
In many cases, I think a simpler (as in more orthogonal) query language can make life a little easier than with SQL. Otherwise I agree with what you say. SQL or not, it's not imperative programming, but playing with sets. Some don't want to see it that way.
For what it's worth, saying something in SQL than saying it with imperative code is much better, I think, given its descriptive properties.
a. Why is it not possible for the relational model to manage data of arbitrary complexity? Current implementations probably can, probably can't, but that says nothing about the model itself.
b. If you can show that natural language research has reached us to a point where it can be used in production systems, then your argument is worthy about asking questions without the encoding process from question to database query. Until then, I would like to rely on the explicitness and preciseness of a query language, despite the fact that I have to "encode" my question into a query language (it seems like this is done all the time in programming, anyway.)
c. You are asserting something based on something I know nothing about (hospital systems). I don't know how you can really even assert your point about the weaknesses of the relational model without first giving me a explanation of the domain that you are using as an example. Even then, the domain could be open to subjectivity in terms of implementation options.
Hey, use what you want. For me, I enjoy the generality and simplicity that the relational model provides. Making it easier without SQL (which I originally was saying) will make it better, I believe.
I see the future now and it will happen in two phases: getting rid of SQL and then replacing it with something half-way decent (like a properly implemented relational algebra.)
That is, unless you are incensed that nothing is ever going to happen in that area of life. When you are faced with it, you'll always look the other way. But believe me, it's not that bad, especially when you don't feel the weight of judgement on you for not partcipating in this venture.
I really don't understand the problem here, and why people must cavil over a non-issue like required whitespace. If you don't like it, don't use it. End of story.