Slashdot Mirror
Enthusiasts Convene To Say No To SQL, Hash Out New DB Breed
ericatcw writes "The inaugural NoSQL meet-up in San Francisco during last month's Yahoo! Apache Hadoop Summit had a whiff of revolution about it, like a latter-day techie version of the American Patriots planning the Boston Tea Party.
Like the Patriots, who rebelled against Britain's heavy taxes, NoSQLers came to share how they had overthrown the tyranny of burdensome, expensive relational databases in favor of more efficient and cheaper ways of managing data, reports Computerworld."
Just use flat text files --- no need for expensive db's .... think of the freedom!
"i lost my dignity on a slippery wiener"
There is a time and place for SQL. There is a time and place to avoid SQL.
SQL is great for financial data. SQL is terrible for genetic data.
This is a boring sig
When you get a lot of morbidly obese nerds with no life to program for you.
Meanwhile SQL users get laid.
Go fork yourself!
Seems to be a silly thing to be against. Relational databases and the stuctured query language may not be perfect, but I bet these people could die in their 90's and people will still be using relational dbs and sql.
If you want to tout open or cheap dbs and more lightweight types of storage/db servers, then they might have some points, but being against sql is just plain dumb.
Too bad they can't protest the current regimes taxes with as much enthusiasm. At least it would be a protest against something that actually matters.
I've seen strong reactions from various camps with regard to concern over saying no to SQL. I'm not sure why people freak out over it. First, you have to strike out toward new things if you want to progress the world. Second, SQL hasn't caused people to stop using spreadsheets or Access databases. Third, there are groups that get together to dispute that the earth is round; insisting that it is flat. Or that gray aliens are visiting earth regularly and probing our anuses.
Bring on the next fascinating data technology. SQL will continue to have a major place for many years to come, no matter what happens.
I keep track of all my car bills and cat names with Notepad and Excel. I don't know why anyone would need anything more than that. If I need to sort my text file, I go to this thing called the command line and use the "SORT" command. If I need to find something in my text file, likewise, I use the command line and the "FIND" command
I thought DEC RDB was a pretty good query language. I never got into SQL as a result. I am glad people are thinking about alternatives.
http://michaelsmith.id.au
...say no to the tyranny of... er.. English. Let's stick with the combination of grunts, squeals, crying and gesturing that has proven so effective for toddlers all over the globe for thousands of years. And if we surrendered the traditional languages that we are so irrationally attached to, who knows what revolutionary new communication scheme the next-generation kids will come up with.
Python?
The problem is the performance of transactions and persistence and distribution of data techniques, not
whether we are using a logic-like STRUCTURED QUERY LANGUAGE to ask for data matching certain conditions.
The latter is still, and will continue to be, very useful.
It's just that now that we can assume local clusters and WANs worth of co-operating data stores, there
are probably better, more performant ways of implementing persistence, replication, distribution of data
than traditional RDBMS implementations.
The two concerns: The logical model of how we QUERY for data (or combine it in bulk), which is the core of SQL,
and how we persist it and retrieve it quickly, now have more options for being separated.
Where are we going and why are we in a handbasket?
It's pretty easy to say "yes" to alternatives without saying "no" to SQL.
Just because a crowbar can pull out a stubborn nail better doesn't mean they should replace all the hammers. Then what would we put nails in with? Different tools for different jobs.
Porquoi?
The idea of RDB is cool, relational algebra is quite neat. But SQL itself is horrible.
I'd like to have a language which will allow me to access intermediate tuples cleanly and return hierarchic structures. For example, if I want to fetch all customers and all their bids in one query I have to use inner join. And that results in LARGE number of rows (Cartesian product of customers and their bids).
Also, I'd like to see stuff which is not easily expressed in relational algebra, like running sums or grouping on a computed field.
If I was to read the article, I bet somewhere someone would be wittering on about Key Value Datastores.
The brainchild of a generation brought up on high level collections, they learn one (in this case Map) and apply it to everything.
Sadly SQL, and RDBMS, works for most people. It maps object data well (oh whaaaa, i have to do foreign keys - GROW SOME FUCKING BALLS YOU LAZY GRADUATE!) and it is well understood. And with abstractions like LINQ to query them, even the lazy dumb Windows .NET programmer doesn't have to strain their brain to learn SQL.
And when you have terabytes of specific unique data, you clearly should go away to work out how best to store it. Even a RDBMS/SQL solution is too generic for all problems.
I'm not seeing anything that offers a real advantage over using advanced features like one finds in postgres combined with memcached. Some of my program likes to think of its data as a structured object while other parts like seeing that data as rows in a table (they even link up to other tables through foreign keys!).
The Patriots themselves levied their own heavy taxes emulating those against which they had originally rebelled
In the end it's all just 1's and 0's.
Hope is the currency of fools
go back to flat files aka DAT files.
Use the old DBase III standard DBF files?
Use the old Lotus 123 WK1 files?
Use MS-Office MS-Access MS-Excel etc files?
Use comma separated values files?
SQL set a standard for relational databases, a structured query language that almost any database can use and then build extensions to it.
Will the Post-SQL age begin, and will it be object oriented and a fifth generation language?
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
Most nails are put in with nailguns. Hammers these days are mostly used for demolition of various sorts, including pulling nails. T
Laws are horrible moral guides, moral guides make even worse laws.
Saying no to SQL and relational databases is just fine if you've got something better to replace it with. However I know of no such thing. The reason they're popular is that they are so powerful for data storage. If something better came along you wouldn't even need to say no to SQL. You'd just say yes to the newer better rival.
These posts express my own personal views, not those of my employer
SQL can suck. The alternatives the PHB might choose aren't necessarily better. Be careful what you wish for.
Like unix being dead - someone else thinks SQL is dead and worthless.
I disagree, there is no ONE solution. SQL works great for many types of data access. But an object based db can be great for other types.
SQL is dead. Long live SQL. :-)
There are plenty of ways to store data inexpensively in a RDBMS. There are plenty of GPL and low cost RDBMS available.
The real issue is that the more and more we move into complex data structures and we push the limits of what an ORM can do with those simple, inexpensive RDBMS, the more problems we run into trying to map our objects into rows in tables.
Here is one of the more interesting solutions that I've seen to the problem, but it only work over relatively simplistic data where managing indexes by hand is ok, and it's okay for the indexes to be incomplete at any given moment. Ironically, that gives them more availability than trying to force MySQL to do indexes. But it really depends on the data and needs.
SQL is not a database, it is a standard interface to a feature set commonly associated with relational models. Before everyone standardized on SQL, there were other relational query languages. The "No" part of "NoSQL" refers to the fact that some basic elements of relational implementations cannot be usefully expressed using a much simpler distributed hash table model.
All the "NoSQL" does is eliminate all the parts of traditional relational databases that do no scale -- discarding the bottleneck rather than fixing it. These are things like joins and external indexing. Unfortunately, discarding those things means you discard a lot of very important functionality as a practical matter, notably the ability to do fast, complex analytics. Adopting the NoSQL architecture runs contrary to the trend toward more real-time, contextual analytical processing. There are a great many analytical applications that are not amenable to batch-mode pattern-matching, and the NoSQL model is a lot less applicable than I think some people want to acknowledge. In its domain, it is a great tool but it has many, many prohibitive limits. We are essentially trading power for scale.
That said, do not take this as an endorsement of traditional SQL relational databases either, as they have a number of serious limitations themselves. As just mentioned, a number of the core analytical operations those models support are based on algorithms that scale poorly. The SQL language itself has mediocre support for many abstract data types (e.g. spatial) and data models (e.g. graph), which in part reflects the inadequacies of the assumed underlying database algorithms (e.g. B-trees) that are implicit in SQL. The inability to efficiently do event-driven/real-time applications is also more a reflection of the access methods used in databases than any intrinsic weakness in SQL; SQL may be clunky for that purpose, but that is not the real limiter.
A truly revolutionary deviation from SQL would usefully implement a superset of the features SQL supports, not take them away. Of course, we would need access methods more capable than hash tables and B-trees to useful implement those features, which is a lot more work than discarding features that scale poorly. NoSQL is a stopgap technical measure for that small subset of applications where the serious tradeoffs are acceptable.
Note that most of these solutions come from the interwebs, social networks, etc. And it isn't so much anti-sql as it is anti-relational database (sql != rdb).
The basic premise is that we need different solutions that: can scale very high for very narrowly scoped reads & writes, don't need to perform ranged queries / reporting /etc, and don't need ACID compliance. And that may be the case. Sites like slashdot, facebook, reddit, digg, etc don't need the data quality that ebay needs.
On the other hand, ebay achieves scalability AND data quality with relational databases. And when I've worked with architectures that scale massively and avoid the relational trap for better solutions - they inevitably later regret the lack of data quality and complete inability to actually get trends and analysis of their data. It *always* goes like this:
Me: So, is this thing (msg type, etc) increasing?
Developer: No idea.
Me: Ok, so lets find out.
Developer: How?
Me: I don't know - typical approach - lets query the database.
Developer: It'll take four+ hours to write & test that query and then days to run. And when it's done we might find that we wrote the query wrong.
Me: What?!?
Developer: We had to do it this way, you can't report on 10TB databases anyhow
Me: What?!? Are you on crack? there are dozens of *100TB* relational databases out there that people are reporting on
Developer: well, we probably don't need to know what that trend is anyhow
Me: I'm outta here
http://www.zope.org/ - both WLS and hibernate made obsolete decade ago ;-)
that "both" - unfortunetaly the case when too much is too much
Check out "Window Aggregates" etc in Oracle and PostgreSQL 8.4
Over-the-top Response Guy! Giving "Over-the-Top Responses" since 1970.
First: my mantra: Data belongs to the organization, not the application... if the app fails and data is accessible then we all go on - if the data fails or is locked away - what was the point of the app again?
In a SQL database then data is understood by the organisation, DBAs and data architects. If left to app developers taking an app-centric approach to data... I get nervous quickly.
So long as the data is just as definable and accessible as current SQL databases then all good - give me an app with some odd-ball storage then it is bye-bye.
Epic Fail. You're wrong. It in now way results in a "Cartesion Product". That would be a "Cross Join", not an "inner join". From my experience, people who complain about SQL and relational database, are, for the most part, ignorant. They really don't even understand what they are saying or what they are talking about. I've seen so much abuse and misunderstanding of relational data and SQL in my career, that I just have to laugh at this sort of thing.
Over-the-top Response Guy! Giving "Over-the-Top Responses" since 1970.
could we see a rise in the use if tree/hirearchial Databases like LDAP?
SQL is an OSS tool?
Why'd I pay so much to Informix around 1990 then I wonder?
For that matter... SQL is a thing? I always thought it was a spec and a language :)
You're special forces then? That's great! I just love your olympics!
That is one view. It's nice and all, but incomplete. The issue is performance.
Any time you're dealing with a large quantity of data, it's always easiest to process or filter where it's located. Transmitting it, processing it, and transmitting back changes adds an unreasonable amount of overhead. Hence, SQL is a "Query" language. In other words, you have the RDBMS do reasonable data processing and filtering of records for you. Your application should only need to specify the operations performed, and should only process data if your computation is particularly unusual. This makes feasible computations that would otherwise be entirely unreasonable. (note that an application working on the same machine generally has the same issue as one working on a separate system. SQL servers present the application with a stream of data - pipe, socket, etc)
My opinion: SQL is horrendous. It's a pain to use, and many basic data transforms cannot be described in that language (at least without some huge, awful, convoluted command == maintenance nightmare).
I won't join Slashcott. OTOH, If Beta goes live, I just won't be back until it's fixed. Sorry Dice.
Python?
If by that you mean "saying no to it", I applaud you. :)
Lua is the only way to program.
Homonyms are fun!
You're driving your car, but they're riding their bikes there.
IBM has had a hierarchical database called IMS since 1966 http://en.wikipedia.org/wiki/IBM_Information_Management_System
It holds and manipulates data in a hierarchy accessed and manipulated with the DL/I query language http://en.wikipedia.org/wiki/Data_Language_Interface
Now, if the venerable IBM would please grow up and Open Source IMS we could have the best of both worlds.
Better still, reverse engineer the thing from IBM specs, dropping all the legacy fluff accumulated over 40 years, and call it MyHQL.
Her lips were softer than a duck's bill, but her quacks
Relational database have plenty of good uses. They are not the universal solution to data storage, but there are plenty of cases where they are the best case. I would certainly not use a relational database just to store user passwords. Something like Berkeley DB would be good. I have used raw files individually (one file per user named by username) with good success (the underlying filesystem was Reiserfs with tail packing enabled). But even where a relation database is called for (a CRM system, for example), I find that SQL is always a hindrance. I'd rather just get the data across a simple protocol (which can be wrapped in a simple API binding for the language in use).
now we need to go OSS in diesel cars
Great job moderator. It's an attempt to make a reasonable point with the help of a deliberately over-the-top analogy. You maynot agree with the point I'm trying to make (that much is obvious), or you may not agree with the applicability of my analogy (which, I humbly submit, is pretty close). That doesn't make it trolling.
Invent the successor to SQL and clueless corporate drones that call
themselves developers but really aren't will come along and abuse
that too.
SQL is a useful construct. What replaces it or augments it should
be similar. IOW, where's the corresponding ACM article for this
holy-grail-SQL-replacment?
As far as SQL representing expensive and bloated DBMS engines, you're
a bit late to the party to be whining about that. Sure perhaps 10 years
ago you might have had a point but any more the overhead of SQL just
isn't there anymore. Cheap/free low overhead SQL engines are plentiful.
SQL in general may be suboptimal but it is a an effective standard.
It allows a degree of standardization and flexibility that will
likely not be matched by a successor any time in the near future.
A Pirate and a Puritan look the same on a balance sheet.
Nah, Perl (or, in Perl, $a = )(J0(JE#R09J@#_)JQ_)@J(!)![RL}).
SELECT * FROM DB WHERE DBCLASS='REAL' QUERY_LANGUAGE NOT LIKE '%SQL%'
0 Rows Returned
(Stupid slashdot yelling filter. I hate queries in lowercase. )
So a bunch of Excel users got together for dinner in San Francisco - why is this news?
#DeleteChrome
I had no idea this was even an issue. Very enlightening indeed.
^^vv<><>BA
Trees is a wellknown problem of SQL
And the "nested set" representation of a tree, explained by Joe Celko, is a well-known solution. Give each node an ID making sure that the IDs' collation is pre-order, and then in each node, store the ID of its first and last descendants. So node B is A's descendant if A.firstdesc <= B.nodeid AND B.nodeid <= A.lastdesc. There are some situations where INSERT statements can become slow (worst case: O(n)), but planning your ID space carefully can ease those.
...What democracy is to methods of government.
The worst ever devised excepting everything else that has ever been tried.
Any insufficiently advanced magic is indistinguishable from technology.
That's who these people are. Google and Amazon in particular have heavy investments in the cloud.
SQL and relational databases work fine for most real purposes, they even scale fairly well. What they don't do, is scale very well via a cloud infrastructure without very serious amounts of data analysis and design. This isn't so much a problem with relational databases or the way they scale, but with the way they distribute. You can't magically throw more small servers at an sql database and make it work faster because they're not designed that way.
Amazon managed to put their databases in a cloud, but only because they did a lot of analysis on their data and found some very convenient patterns. Those patterns don't directly translate to other data sources.
If you have to spend half a million dollars redesigning your database it's cheaper to buy servers than to pay Amazon to host them in the cloud. Amazon and Google both want you to pay them to host your data in the cloud. For obvious reasons that means they want a new database system which works well when applied in small amounts over their "computational unit" servers as opposed to when stuck on a gigantic powerful single server as is the case with current SQL databases. They don't really care if their new alternative is actually any better, just that it's good enough that people find it cheaper to use the cloud, if they can get a cut of the use of the technology as well as the hosting, all the better.
I did my BSc in Information Systems 9 years ago. A strong part of the practical in the final year was Oracle DBMS with SQL but along with theory about object oriented dababase and modeling.
I doubted back then that OO in databases would see the broad use light of day.
I still think its years away. Its all very good for a few visionaries who are clever with coding wish to see their better mouse trap take control of data. But in the real world when an agile business needs to step up to the plate on a monthly basis to adapt to some crap board decision that you have no control over then DBMS's allow one to respond to their decisions.
In post Patriot Act America, the library books scan you.
RDBMS systems focus on Consistency, and trade Availability for it. Your bank's computer can be down for an hour... inconvenient, but acceptable. But they cannot, under ANY circumstances, be incorrect. Period. Google, on the other hand, can handle some slightly incorrect data... but being offline is totally unacceptable.
You can simulate this behavior in pure SQL by inserting from a select. This makes a table that caches what needs to be cached on each partition.
You can even TRIGGER this to automatically update when practicable, giving similar functionality to the "materialized view" features in some DBMS implementations.
Use the appropriate tool. Always. There are tons.
Don't use a relational database to try to represent hierarchical data. Don't try to use LDAP to do analytics. Think of the performance implications before you have more than two users accessing your system. Data storage is a very different animal, you are often (though not always) I/O bound. This is very different from being limited by the amount of instructions you can deal with per unit of time. Don't think otherwise because it will bite you in the ass.
And still I see people making the same stupid mistakes over and over. But it's pretty simple really:
A solution designed to be generic will ALWAYS be slower than a solution that is customized. This shouldn't be surprising. If you have serious performance requirements (ESPECIALLY if they are coupled with huge amounts of data) then a custom solution is definitely something you should look into. At some point you will run into a brick wall and find out that there is stuff you can't do with the solution you have in place. This is natural. Custom solutions to hard problems always lead to restrictions in terms of future features. Always. You will NEVER be able to anticipate all features that you would like to have. (Yes, this is true for Google as well. No they don't have any special kind of magic dust that they sprinkle on their things there, they do the best they can and then they get bitten in the ass too, just like everybody else.)
I've had a wonderful time, but this wasn't it -- Groucho Marx
I must be getting old, but there are many types of simple table based systems around and they used in things like sendmail, postfix, squid-cache, round robin database, look aside tables, computer instruction caches and so on. This istuff is nothing new. It is a matter of using the right tool for the job without the need to consult an oracle.
Excuse me, but please get off my Pennisetum Clandestinum, eh!
See, I don't think there is ever a good time or place for SQL.
SELECT text FROM mild_introductory_statements WHERE id=random();
Anyone who says so has never had to use it.
SELECT text FROM statements_indicating_superior_experience WHERE id=random();
I like to compare it with JavaScript.
SELECT text FROM unrelated_tool WHERE id=random();
It's a language that is difficult to refactor, maintain, and while it's a standard, the standard is so vague that it's useless.
SELECT text FROM seemingly_valid_yet_unsubstantiated_objections WHERE id=random();
Like JavaScript, people are trying to build other languages on top of it to hide its shortcomings -- for javascript you have tools like GWT, and for SQL you have HQL, Linq, etc.
SELECT text FROM wrongheaded_causal_analysis WHERE id=same_one_as_two_queries_ago();
Not to say that there is anything wrong with relational databases, we just lack a good tool to interface with them.
SELECT text FROM reasonable_sounding_parthian_shot_to_obscure_trolling WHERE id=random();
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
That article you linked to is one of the craziest things I've ever read. RDBMSs are powerful enough to do anything -- but so many engineers are too lazy to learn proper SQL.
If you need to handle more transactions or queries, buy a bigger box. You can have hundreds of TB in a nice enterprise-grade server. If you HAVE to run your data across multiple machines, just spend some time and actually *think* about what data you want where, and then write a little code to send it to the right database.
Even Google used a ton of MySQL boxes for a long time to deliver their searches. Scale-out architecture is a lot more of a lie than its proponents make it out to be, check out this post on CodingHorror.
Eventually, all these new "databases" will need to actually be used in a *real* environment, and they'll have transactions, SQL support, indexing, a good UI, and everything else. All MS or Oracle need to do is a little tweaking to make their multi-box configurations more robust, and they'll crush everything else.
The problem with the existing RDBMS is not so much relational nor SQL[1], but the fact that they are not dynamic. Why not allow columns and tables to be created willy-nilly and without (up-front) width limits, like in a dynamic programming language? It would need a more flexible type system, or even do away with internal types and make the operators a bit more type-explicit, like Perl does. We have static/compiled programming languages and dynamic/interpreted programming languages. Why not have a similar choice with RDBMS? Stop cloning Oracle's style of relational so closely.
[1] There's a few minor tweaks that could be done to SQL to improve some really sore spots, like named temporary query references, a kind of user-defined and/or temporary views. This would reduce run-on sentence queries. There's also graph and tree traversal query needs, but somebody pointed out that these already exist to some extent.
Table-ized A.I.
I created a draft query language called SMEQL (Structured, Meta-Enabled Query Language, pronounced "smeegol"), which is roughly based on IBM's early BS-12 language. It partitions relational operations at a finer level than SQL clauses and allows one to use named references such that one does not have to massively nest sub-queries. It borrows heavily from FP concepts. It also has a simpler syntax than SQL, making it easier to create DBA-defined extensions. I just wish some bored sucker locked in jail or something would program a production version of it for me. Hans Reiser? :-)
http://www.c2.com/cgi/wiki?TqlRoadmap
Table-ized A.I.
I created a draft query language called SMEQL that purposely allows better partitioning and reuse of concepts than SQL. I described it in a nearby reply. It borrows heavily from "functional programming". The problem is that it only exists on paper. Sigh.
We have thousands of app programming languages, but only three[1] relational query language contenders: SQL, Tutorial-D[2] (and derivatives), and SMEQL. Time for some real competition to SQL.
[1] There are some older ones, but most consider them "legacy" and I see no interest from others in reviving them.
[2] Tutorial-D's syntax is unnecessarily complex in my opinion.
Table-ized A.I.
Dah! Everyone with any technical skills has known for many decades that relational database are junk. Sure they do a particular job but then so does a swiss army knife but you'd not use it to cut a forest down you'd get a proper volume tool and nothing beats object databases with a simple file structure. Flat files are great too however they tend to require extra parsing slowing things down. You can roll your own object database system easily even with full on transactions and concurrency support in under a man month. Death to Relational Databases.
Trash SQL in favour of coding all your data access needs. Welcome back to 1973, guys.
It's not like we could do parallel SQL in the 1980's. Or that you can't do parallel SQL in a compute cloud today.
No, It basically seems like they don't want to pay software vendors any money for database technology. That's mostly what the arguments boil down to. Oracle RAC is very scalable, arguably easier to do at massive scale than MySQL - but you have to pay Oracle money. For an Internet startup, I can understand why you'd take your chances with "roll your own". For an enterprise... I think not.
-Stu
Think of the discussions!
Yawn... they said that about Cobol... call me when they have actually eliminated Cobol... and in my opinion is a much larger horror than SQL.
SQL is here to stay... maybe a few enhancements... but it shouldnt change much... too much of criticial stuff is dependent on it... besides, it's surprisingly flexible when it comes to access data
Never antropomorphize computers, they do not like that
You can use SQL with flat files.
SQL is going to be around for a long time, because it's useful as an "API" - as a protocol or layer of abstraction.
Programmers can write all sorts of programs in all sorts of programming languages and then use SQL to talk to the DB. If the DB changes a bit, they can often use the same SQL or modify it slightly.
You often see lots of grumbling and cursing in various companies because people actually end up doing that and companies end up with lots of stuff hooked to the DB - MS Access, perl, python, ruby, java, radius servers, openvpn, accounting and finance stuff...
They grumble, but the fact is the database is being used. The data has become more useful.
If you have your database locked up behind some new fangled protocol that only 20 people in the world know, it's not going to be as easy to do that - and often each bunch will start creating their own databases and you end up with a different mess, and a mess that's not as useful.
Having everyone use SQL to talk to the DB is not actually a bug it's a feature.
One man's impedance mismatch is another man's layer of abstraction.
SQL syntax sucks, is inconsistent, and just non-standard enough at its corners that it's completely annoying to write anything for more than one DB. Also lacks various features which logically _should_ be there, because of the relational back-end. SQL is a toy, and though I'm the guy everyone in the office turns to if they want to write a query that does more than SELECT * FROM sometable, that doesn't mean I have to like it.
But that's not the fault of relational databases. The relational logic makes sense, and we'll be seeing it referenced in countless "new ideas" that come along for years, just as ideas which Lisp already had in 1970 will be touted a new features on for the next millennium (you hear? PHP can do Lambda functions as of yesterday!)
SQL sucks, but SQL is NOT what makes something relational.
-- 'The' Lord and Master Bitman On High, Master Of All
Are the two sequences equivalent, in that they both code for the same thing, like (just an example) red hair? In which case the solution should be another layer of abstraction plus a join; get the code(s) for being a carrot top and find everybody who has them.
If they aren't coding for the same thing, why would you want them both returned anyway?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Derby 10.5, meanwhile, still has a tiny footprint, and can do most if not all of the SQL you will ever want for a typical Java application, along with features like the ability to do live backups, live table compaction from within the application while running, and now at last the ability to do cursoring in SELECT statements. Installation and configuration are simple.
I actually think that the actual problem is that we old C programmers actually learned programming and data structures, and as a result know a lot about the kind of problems for which SQL is well suited, while a lot of modern programmers learn a lot of theory about OO, but don't actually learn to program. Therefore, they have to try to reinvent wheels that were in fact designed in the 70s, and have no idea of what tools are available and how they map onto typical real-world application level problems.
From scarped cliff or quarried stone she cries "A thousand types are gone, I care for nothing, no not one."
But still, props for actually doing something, rather than most of the other whiny pissants in this story whose comments can be summed up as "I've never learnt anything beyond an inner join, therefore SQL sucks."
My Biggest problem with sql is that i have defined my database as a graph, but I newer get data back as a graph. Example for slashdot.org:
There are users, who can post stories and there are comments to each story. Imagine that I want all users that have postet a story, where a comment contains the word Amiga. And I also want the stories, and the comments that contain the word. With sql that's easy, I just do a join between user and story, and between story and comment and take the comments that contain the word amiga.
No problem, EXCEPT that what I get back is a bag of data with no specific order(And with much redundancy). That's not what I want.
What I want is a list of users, and for each user I want the stories that he have submitted with at least one comment that contain the given word. And for each story I want the all the comments that contains the word. The sql does contain all the information i need, but extracting it is quite some work.
My database is defined as a graph where foreign keys are the links, so why does sql(And relational algebra) insist on not using this graph when returning data?
I do it all the time,
I add a string key, e.g., AAA_BBB_CCC_DDD..... and alpha index it
To find all the offspring of AAA_BBB_CCC look for like 'AAA_BBB_CCC*'
To find all the siblings of AAA_BBB_CCC look for like 'AAA_BBB_%%%' where % is a single char wildcard.
As a DBA for a major well know RDBMS product, we get this crap every few years, "A new paradigm!". Yeah well the first time you load you wonderful no optimised SQL into any puckka RDBMS system, it will balk and like a bunch pre-schoolers all go crying to thr DBA that you app won't work any more. It worked fine with 2 test users, but now with 2,000 it balks and crashes! Duh! Wonder why? 'Cos you're a plank who believes all the RAD product BS!
How many times have we now had somebody announcing "the end of" something? COBOL, FORTRAN, C, mainframes, UNIX - and now SQL. All these things are still around because they serve a useful purpose. It is well possible that this "No-SQL" concept can serve a purpose other than hype, but that largely remains to be seen.
The big, fundamental advantage of SQL databases, as far as I can see, is not that they are transactional or scalable or fast, but that you can organise your data in a way that fits fairly naturally with your data, and then you can analyse things in ways that you hadn't thought of when you designed the database using the select statement, even if it isn't always the most efficient of tasks. This is one thing that is hard to build in to hierarchical or networked databases, and of course even more so in simple, indexed files. And that is why RDBMSes are going to be the most important kind of databases for a long time yet.
That is not to say that simpler mechanisms don't have their place; few things beat a simple ISAM file when it comes to whipping up a program that can quickly look up and organise a simple dataset.
I'm not surprised; these are probably the same class of people who maintain that MS Access is all you need for a high-traffic website backend.
They're also the same class of people who are at a loss to explain why their site/application is so slow under load...
Stupid dummies.
Then again, I haven't RTA, so I'm probably babbling.
Anyway, it's Friday and it's been a long week dealing with fuck'n dummies who don't apologise when shown the error of their ways, so fuckit, fuckthem, fuckemall. Say ghello to my leetle friend...
And works well. Let them go off on their own and play around, and let the rest of us get some work done.
What is next, complaining that wheels aren't the coolest way to get around town?
---- Booth was a patriot ----
SELECT text FROM thank_you_for_sharing_your_views_but _you_have_not_seen_the_schema_my_friend
UNION
SELECT text FROM same_goes_for_point_two__if_you_lack _the_source_code_what_then_do_you_really_know
UNION
SELECT text FROM besides_it_got_plus_five_funny_so_neener_neener_neener;
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
There are some people who have reasonable objections against pressing data in a relational scheme because they really understand what it cant do for them and there are some people who have unreasonable objections against it because they really dont understand what it can do for them.
who hasn't had a business need for multiple levels of aggregates (eg averages of sums across multiple groupings, say "average across all customers' total balances") As it is, you end up splitting the logic between the database and the application
This is one class of problem Prolog or Datalog or some other variant would be great at, and I often wish not so much that I had a non-relational database as I had a better way of querying relational data.
Tweet, tweet.
I've been struggling with maintaining someone else's multiple, redundant, pointless layers of abstraction that all need to be updated to add a F-ing field to a table. If I ever meet the guy who created it in a dark alley, I'll surely injure him severely (i.e. Cave his skull in with my bare hands).
It drives me crazy when developers can't get the understanding that the DATA is central, not their idiotic layers of abstractions and so-called "Frame-Works" (I'm going to vomit now)!
Over-the-top Response Guy! Giving "Over-the-Top Responses" since 1970.
I just spent 3 months doing cloud computing where we used a 'columner database' similar to big table. We got around the problems because the database was auto indexed lexigraphically by key and we'd make up different keys to help us index the data to find various 'cells' of data quickly and easily. It was beautiful because if we decided a day later that we wanted a new column, we just changed our keys to include the new column and it was there. That way we could quickly prototype, eventually settle on good 'table structure' for lack of a better term, and we could withdraw results very quickly. We could also add new columns much later if we needed to, like if we wanted to store totally different types of data in the same tables later.
The downside to this database is that its very inefficient for rapid transactions. So you would never use it for something like ebay, where the records change 'status' (from for sale to sold). But you could easily use it for something like craigslist or google which stores __lots__ of data that doesn't change.
Sig 'em boy!
The "with" clause definitely looks promising. I hope it or something like it becomes standard. Another way that may require less new syntax is to use the existing INTO clause with some special character or sub-clause, something like this:
SELECT AVG(grade) AS GPA INTO $T1 FROM Grades GROUP BY studentID;
SELECT AVG(GPA) FROM $T1;
OR
SELECT AVG(grade) AS GPA INTO VIRTUAL T1 FROM Grades GROUP BY studentID;
SELECT AVG(GPA) FROM T1;
Still, SQL is syntactically far more complex than needed in my opinion. I attempted to address that in my pet language by using a simpler syntax style. A DBA could add a new "operation" without having to change the syntax.
Thanks
Table-ized A.I.
If you think anyone with half a brain will program a production version of a spec created by a megalomaniac bastard that calls coders 'suckers', then you either have a lot of money or are delusional.
Nerds need and deserve respect.
We are Turing O-Machines. The Oracle is out there.