Unified NoSQL Query Language Launched 194
splitenz writes "Hoping to unify the growing but disparate market of NoSQL databases, the creators behind CouchDB and SQLite have introduced a new query language for the format, called UnQL (Unstructured Data Query Language — .PS). It has Microsoft's backing."
Obligatory xkcd (Score:4, Funny)
Re: (Score:2)
More than standards: www.arnnet.com. I will never understand how greed can get someone to serve an ad to some random user instead of the article the user requested in the first place.
If I come to view an article and I don't, I deem the website broken and I leave. I will NEVER again click on a "skip this ad" button. This is just going way too far. If they don't want my eyeballs on their content, that's perfectly fine with me. But they won't have my eyeballs on their crappy advertisements either.
Re:More than advertising (Score:3)
I have the opposite problem. If a website doesn't work with NoScript enabled, I deem it broken and never return. I don't have AdBlock, they can show me ads, but not like what you're describing.
I saw an article when I clicked.
Here's the idea. It's my computer, my processor, and if a website wants me to run something they need to ask permission first.
Re: (Score:2)
Re: (Score:3, Insightful)
Relational databases work well for certain types of data but to assume that tables of rows and columns work for every need is silly.
Relational databases are inherently hard to scale because they mix data together that doesn't necessarily need to be together. If there's no reason why Bob and Alice's records should be in the same table or on the same machine then they shouldn't be. You can avoid all contention by distributing each individual's records on unique or underutilized machines.
Relational databases d
Re:Can somebody explain NoSQLers to me? (Score:5, Insightful)
Have you ever used a relational database?
Every NoSQL approach, be it document-oriented, key-value storage, or the various hybrid approaches, can be very easily implemented using relational techniques. In fact, they are all just subsets of the relational model. Key-value storage is merely a two-column table, for instance.
Basically every decent relational database system today allows you to easily partition your data in almost any way possible. It's trivial to store or replicate a single table's data cross hundreds, thousands, or even tens of thousands of storage and processing nodes.
Relational databases work very well for storing hierarchical data, as well. Recursive common table expressions make it extremely easy to work with such data.
There's just no reason to use a NoSQL database. Relational databases can do everything a NoSQL database can, and then a fuck of a lot more.
Re: (Score:2)
Yep google got it all wrong they should have implemented their search on a relational db instead of big table.
There is nothing wrong with relational databases they just are not designed to handle the transaction and latency rates required by some applications.
Re:Can somebody explain NoSQLers to me? (Score:4, Insightful)
I'm curious, what happens to all the objects in your object store when the application changes?
Re: (Score:2)
Even as a CouchDB user, I've found your comments in this thread interesting, thanks. You might also like the book "Data & Reality" by William Kent on information representation:
http://www.bkent.net/Doc/darxrp.htm [bkent.net]
I agrre with you that changing application needs is a big issue, no matter what system you use.
That said, CouchDB's easy peer-to-peer replication is still pretty neat. :-) Can you point to a FOSS SQL-based system that can easily match that specific feature?
Re: (Score:2)
PostgreSQL supports all manner of replication [postgresql.org], I imagine it's not as easy as something called "easy replication" but would count on it being more flexible. Or use one o
Re: (Score:2)
Thanks. It is suggested here that "Multi-master replication" is not supported, which is what CouchDB excels at.
http://wiki.postgresql.org/wiki/Binary_Replication_Tutorial [postgresql.org]
Contrast with what is easy in that regard for CouchDB:
http://wiki.apache.org/couchdb/Replication [apache.org]
Anyway, everything has strengths and weaknesses in different situations. But in general, I agree SQL systems can do a lot as a mature technology, and maybe more than some NoSQL advocates understand or are willing to admit.
A
Re: (Score:2)
Data & Reality looks like an interesting read for sure, I will add it to my queue th
Re:Can somebody explain NoSQLers to me? (Score:4, Interesting)
And then you ha0ve a use case change. Or need to interface with an app written in another language. Or find that *shock* while a certain object is very effective for holding some information, it's a horrible way of storing for query. An object should be designed for the use case at hand, the database should be designed for efficient retrieval for that and future use cases. The two are damned near never the same. Persistence frameworks are a mistake.
Re: (Score:2)
the automapper
I think I found your problem
Re: (Score:2)
Re: (Score:3)
The object/relational impedance mismatch is often cited by people who think they should not have to model information to persist information (they mistake their object model for an information model). While it's almost always worth your while to design an information model behind your objects, in the case that it's not you don't have to. Either way
Re: (Score:2)
What happens if keys point to different types of data (images, text, movies, urls, other tables)?
In that case, you should be using something like SQLite. See this page [sqlite.org] for more information.
Re:Can somebody explain NoSQLers to me? (Score:4, Informative)
Try to read CJ Date work on relational theory and relational databases. Every single thing you say is wrong, I'm sorry to say that. Relational databases are not about "fixed column data models". It's not an ACID Excel. It's not about tables. It's about sets and how sets relates to it's members and to other sets. This includes hierarchical models, which are easily expressed in a RDBMS.
Those who doesn't understand relational databases are bound to reinvent it, poorly.
Re:Can somebody explain NoSQLers to me? (Score:5, Informative)
Re: (Score:2)
Neither movie files or medical records are unstructured. No data with meaning is.
In fact, there's a great case for putting your "blob" to a relational database through a filter that gives it structure - after all, it's a good thing a doctor could access his patient's entire medical history but not name, right? Easy to do with SQL, impossible to do with blobs.
Re: (Score:2)
Relational databases do not work well for storing hierarchical data like a file system or an object-oriented data store. They do not work well for large blobs like movie files or for unstructured documents like medical records.
Emphasis added.
This is part of the problem I have with NoSQL. It is a great solution to certain types of problem, but a lot of data is structured. Medical records are extraordinarily structured and should be stored as such. Structured medical records means portability, easy epidemiological research, better use by consumers, finer control of authorities...
Structuring medical data is hard, no doubt. But that doesn't make it unstructured data. The benefits of structure are significant. Use NoSQL for things i
Re: (Score:2)
I worked with medical records, stored in HBase with minimal structure. The application dealt with statistics over millions of patients. Missing a few elements of a record by the time a processing job went looking for them was practically irrelevant, and even desirable sometimes. By discarding most of the structure of the data, the meaningful information could be summarized in a concise form suitable for the needs of the application. The application I worked on could deliver results from scratch in 3 hours c
Re: (Score:3, Insightful)
I just don't get NoSQLers at all. Can somebody explain them to me? So they have trouble scaling systems using existing relational databases because they don't know about indexes, or data partitioning, or how to set up proper hardware configurations for database servers. (Keep in mind that the system they're "scaling" is a blog getting 50 hits per day.)
Generalizations + lies + attempt to ridicule without facts in hand
Their solution to this problem is to avoid relational databases completely, instead opting to use so-called "NoSQL" databases that don't offer ACIDity, or basically every other useful feature of relational databases.
Apparently obvious to the fact that in many non-trivial business cases, you don't need full ACIDity and an eventually consistency model is more appropriate.
Then again, many of these NoSQLers don't even seem to know what transactions or referential integrity are in the first place, so maybe they don't even realize what they're missing.
Generalizations and unsubstantiated blanket statements about a group of software engineers for the mere sake of ridicule (this in contradiction to the first question that is dishonestly presented as a genuine question.)
When they find out that their NoSQL database has corrupted or lost data, they start trying to hack together application-level support for stuff like transactions and constraints.
Generalization, speculation.
It doesn't work, and may in fact cause more problems than it actually prevents.
Generalizations + hand waving (surprisingly
Re: (Score:2)
Try that again, but without so much ad hominem, and without using "generalization" as your only argument against what was said.
It's hard to take you, and other NoSQL advocates, seriously when you don't present sound arguments.
Ad hominems. How do pot-kettle. Instead of telling me that I'm ad hominem'ing you, tell me exactly which of the accusations I made (generalizations and ridiculing) is not true. Then we talk.
Also, I'm not a NoSQL advocate at all. I'm a whatever-works advocate. For the majority of cases, for the general case, a relational database system works just fine. For a certain class of problems, it doesn't. Use the tool that is appropriate for the task.
But then again, you are free to generalize me as a NoSQL advoc
Re: (Score:2, Funny)
Mr Breivik, is that you?
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Actually no I am not running a blog I am running a gaming system running well over 300k transactions per second at peak load.
It is also a requirement that I be able to run this on virtual instances so that if I need to double in size in the next 24 hrs I can do it.
It has nothing to do with being able to put a index on a lookup column. It has everything to do with insane transaction rates not obtainable using a traditional approach.
Then there is also the cost factor, I need to run on as few instances as poss
Re: (Score:2)
The article seems mostly about an expressive language for querying xml trees. Its not simple, and totally different from the relational database model. If anything it is more expressive than sql, which is quite procedural by comparison.
Ah the cycle continues (Score:2)
Unified NoSQL Query Language
You mean, like a No Structured Query Language Query Language?
UnQL - Unstructured Data Query Language
Oh... Wellp, I'm always going to read this as "uncle". Then again I always read SQL as "squeel", so I'm far from the authority on abbreviations, but strangely enough I always read NoSQL as "No Squirrel".
It has Microsoft's backing.
Queue flamewar in 5.. 4.. 3..
Re: (Score:2)
FTFA :
UnQL, pronounced "Uncle"
What flamewar? (Score:2)
Having backing from Microsoft just makes it irrelevant.
Re: (Score:2)
No flamewar necessary. Oracle is the new evil overlord.
Having backing from Microsoft just makes it irrelevant.
I'm sure Oracle would be offended by your implication that they've only recently become evil.
Re: (Score:2)
SQL isn't an acronym, it's just a series of three letters that get pronounced as such. It's not fundamentally any different than FBI, FDA or DSHS in that respect.
Re: (Score:2)
According to the author of the O'Reilly book Learning SQL, SQL is not an acronym.
Re: (Score:2)
East coast here. I pronounced it S-Q-L until I moved to California, where my boss pronounced it 'sequel'. That has stuck and now I'm pronouncing it 'sequel', even though I'm on the east coast again.
Re: (Score:2)
I've always thought "NoSQL" is a dumb term and idea because it's nothing more than a negative position. Its proponents seem to be anti-SQL, though not necessarily for all the same reasons. In many cases, people seem to be equating SQL with the relational model and abandoning the latter because of deficiencies in the former. UnQL seems to be bringing things full circle in that its designers realize that there's no sense in abandoning the relational model and all work done on query languages so far. It's incr
Re: (Score:2)
Trivially (Score:3)
It has Microsoft's backing."
It won't work.
Re: (Score:2)
Yet your boss will read things on glossy paper and make you use it.
Re: (Score:2)
Re: (Score:2)
Unless you're selling an end-user product, which hardly ever happens in IT, you rarely get to choose what you need to interface with.
Re: (Score:2)
Won't work as a language, or as a way to generate revenue? I'm guessing that Microsoft is more concerned with the latter.
About time (Score:2)
Hopefully the other DBs get on board with this, especially MongoDB and Cassandra, which at the moment seem to be the most advanced and stable. At least that in the future it would be much easier to test and/or migrate from one NoSQL DB to another. Easier options are a good thing !
For example, we've been looking into using a NoSQL solution for storing certain elements of our web application. Unfortunately, it's hard to test the advantages and disadvantages of each without rewriting the connection and logic c
Re: (Score:2)
Re: (Score:2)
Wait, wait, wait... I thought the whole point of NoSQL was that not only were you able to free yourself of schema's and traditional DB related fluff, but you got a subset of features that were tuned to a specific range of use cases.
The fact that NoSQL has no standard level of commonality between implementation has provided fertile ground for programmers to enhance what they feel is important. If we standardize NoSQL then people will begin to focus more on the core functions than the fringe functions, at s
Just in time! (Score:3)
There was way too much experimentation and innovation going on in the NoSQL world. This should help kill it.
Re: (Score:2)
Re: (Score:2)
Yes, we've known about these ideas for decades, if not centuries in some cases.
Clue me in. Which of these ideas have we known about for centuries, that the NoSQLers claim to have (re-)invented?
Otherwise I mostly agree with you. I get the impression, for instance, that memcached was invented by Zberg strictly because he couldn't wrap his ego around SQL and thought he was so smart that he didn't need to waste time understanding it.
Re: (Score:3, Interesting)
"Fast-forward to the 2000s and 2010s."
This is the issue, fast forwarding to 2010 we are dealing with scaling and environment issues that your precious relational database cannot solve.
Tell me mr genius how you are going to handle 300k select queries on you mysql database holding 10 million rows, running on a virtual instance with shitty IO. Now add the fact that you have a very limited budget etc.
NoSQL stores are designed to address this sort of scenario not your little app with a hundred concurrent users h
Are you for real? You're not joking, are you? (Score:2, Informative)
This is the issue, fast forwarding to 2010 we are dealing with scaling and environment issues that your precious relational database cannot solve.
Relational databases can scale just fine. It's merely fools like yourself, who are fucking clueless, who have trouble getting them to scale. The problem isn't relational database technology; it's the morons incorrectly designing and implementing the systems who are at fault.
Tell me mr genius how you are going to handle 300k select queries on you mysql database holding 10 million rows, running on a virtual instance with shitty IO. Now add the fact that you have a very limited budget etc.
Well, I would clearly use a real relational database, rather than MySQL. See, using MySQL was your first big mistake. PostgreSQL and Firebird make fine alternatives, and they fit very nicely with your "limited budget" constraint, conside
^------ THIS (Score:2)
...THIS...
RDMS Scale poorly because of poorly trained dev/admins. I've walked into 10s of shops and _laughed_ at their production RDMS. They would throw hardware at a problem that was from the outset simply poorly engineered. in fairness, most of these VLDB systems were built by glorified 'power' users who just kept hacking away at a problem. Bravo to them for making something work, but at some point when your whole business depends on this intern-built multi-TB database, you need to bring in an expert.
You
Re: (Score:2)
Oh I know all of these .com shops that are running nosql solutions are doing it wrong because they don't know how to use a relational database?
Again we are not talking about your little app with a 100 to 1000 concurrent users hanging off of it.
Re: (Score:2)
This is 100% bullshit and you (should) know it. You tout yourself as some sort of RDBMS person, but you come across as knowing absolutely nothing.
At the end of the day, Firebird, Postgres and Mysql all really only support one index type (or variant): b-tree. No matter where your data is presently (index or ram), you will ALWAYS pay a price for insert, and ALWAYS pay a price for select. Now, the number of i/os required for a btree seek is a very attractive equation for anything under the 10s or even hundreds
Re: (Score:2)
Tell me mr genius how you are going to handle 300k select queries on you mysql database holding 10 million rows, running on a virtual instance with shitty IO. Now add the fact that you have a very limited budget etc.
There are scenarios where NoSQL is a valid alternative, this is not one of them.
Re: (Score:2)
10 million rows? That should fit in most database servers main memory.
Oh, and if your I/O is the trouble, NoSQL wont magically make it disappear.
The only thing NoSQL has solved is doing multimaster cheap, yes those are hard to solve in traditional databases, however, you can only solve it, if your datamodel is ok with eventually correct, most business aren't.
Re: (Score:2)
If you're willing to spend a lot of money, perhaps. But if you want to run on the cheap, where you've got more time than money, NoSQL database provide excellent performance. I'm working with an Oracle Enterprise installation, and it just cannot compete with the 30M rows that the Hypertable db on my laptop can serve up in a couple of seconds. Perhaps if the DB guys threw a load of money at it, Oracle could do that too. However, using Hypertable means that you have to write a lot of extra code. That's not goo
Re: (Score:2)
I'm working with an Oracle Enterprise installation, and it just cannot compete with the 30M rows that the Hypertable db on my laptop can serve up in a couple of seconds
Then you have incompetents running your database if it's having issues with a measly 30 million rows. That's fucking childs play. It's not uncommon for a enterprise databases to be handling hundreds of millions if not billions of rows of data and they do it just fine in the hands of people who aren't incompetent.
Re: (Score:2)
It's not that the data cannot be stored, we've got billions and billions of rows. I just cannot get 30M rows returned from the server in a couple of seconds; that takes ages under Oracle, whereas Hypertable returns them very, very quickly. E.g. fast enough to generate reports on the fly.
PDF version of paper (Score:3)
Link to PDF version of paper: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.33.3465&rep=rep1&type=pdf [psu.edu]
Wrong link in the summery? (Score:4, Informative)
which funnily enough is linked in the summery.
Maybe you should fix this to point to the actual link in TFA http://wwww.unqlspec.org/ [unqlspec.org] ?
Not standard, unified. (Score:4, Funny)
"So, everyone will use this unified query language?"
"Yes, it'll be great. No need to rewrite things when moving from one database to another."
"Sounds great. Portable apps! Hooray!"
"It amazes me that nobody has ever done anything like this before."
"Yes, in hindsight it's blindingly obvious. There should have been a single query language all along."
"A single query language--we could call it `S-QL` or something like that."
"Nah, I heard that there's already something called SQL. People would get them confused."
"Why? They're probably totally different things."
"Yeah, probably. It's better to make up new names than to risk confusion. So, what's it called?"
"Uncle."
"Isn't that what you say when you surrender?"
"Yes, but in this case there's no possibility of confusion."
Re: (Score:2)
Then all they need to do is reinvent ACID and they'll have made it to the 1980s.
Wouldn't that be the 1960s?
Re: (Score:2)
Then all they need to do is reinvent ACID and they'll have made it to the 1980s.
Wouldn't that be the 1960s?
Having sat in on technical debates among users of different NoSQL implementations, I would say they have plenty of that type already.
It was kinda scary sitting with a roomful of heavy-duty NoSQL users debating technology and having the organiser ask if anyone had any experience across a range of NoSQL implementations, to allow comparisons to be made. Zero hands were raised. This led to an extended debate about "How can we know X is a good approach if we have no idea how it compares to anything else?". The i
get(key) (Score:2)
The beauty of a nosql store is defined by this query method get(key) it need to be nothing more and nothing less than that. Adding a query language totally defeats this purpose. Not to mention once you commit to using a search mechanism you are tightly bound to it.
For instance I use mongodb but I do not allow anyone to use it's built in search mechanisms other than find by some key within the app itself.
Sticking to this rule allows us to move to something like pure memcached, membase etc as a store by a sim
Re: (Score:2)
The beauty of a nosql store is defined by this query method get(key) it need to be nothing more and nothing less than that. Adding a query language totally defeats this purpose. Not to mention once you commit to using a search mechanism you are tightly bound to it.
For instance I use mongodb but I do not allow anyone to use it's built in search mechanisms other than find by some key within the app itself.
Sticking to this rule allows us to move to something like pure memcached, membase etc as a store by a simple config change.
Now using search capability outside the app is handy but again tightly binds you to the platform.
Yeah, I yearn for that beauty when I use PostgreSQL. If only I had to write pages of new application functionality every time I wanted to search in a different way or add a new kind of thing to my database. Who wants to write a couple of lines of SQL when you can write hundreds of lines of C++?
Re: (Score:2)
This will make nosql stores even *more* Web Scale (Score:2)
http://www.xtranormal.com/watch/6995033/mongo-db-is-web-scale [xtranormal.com]
And In Other News... (Score:2)
And in other news, wheel reinvented, news at 11.
SPARQL (Score:2)
So, this is better than existing unstructured languages like SPARQL [wikipedia.org], how?
Re: (Score:2)
SPARQL belongs to the RDF la-la land, so it's designed by academics who never tried to implement anything convenient and scalable.
Just ask them how easy it is to store and query a semantic equivalent of an ordered list of strings.
Re: (Score:2)
Re: (Score:2)
Why else would MS get involved...
Because nobody wants SQL Server, and they need to spread some more FUD about its competitors.
Re: (Score:2)
I doubt that. Microsoft's extend and embraced version of SQL has XML support using XQuery. They are obviously looking for someone like Sybase, the origin of msSQL, to unify the sql language to handle queries on both XML and Relational Data without switching languages. I mean really, how else can Microsoft "invent" it?
What a major f* fail in citations (Score:4, Informative)
splitenz writes:
"Hoping to unify the growing but disparate market of NoSQL databases, the creators behind CouchDB and SQLite have introduced a new query language for the format [arnnet.com.au], called UnQL (Unstructured Data Query Language [psu.edu] — .PS). It has Microsoft's backing."
Then, FTA (right at the bottom of it):
This version of UnQL has no relation to an identically named unstructured data query language proposed by a University of Pennsylvania researcher over a decade ago [acm.org], Phillips said.
I know it's slashdot, but c'mon. Just looking at the linked postscript file shows you a major WTF discrepancy. First the paper is from 2000, and then that paper's query language is based on algebras that do not resemble Codd's relational algebra at all. And that runs counter to this, also FTFA:
Like SQL, UnQL was built on the foundation of relational algebra, Phillips said.
The news are great. The coverage blows. It would pay to read the stuff that is being submitted as a story... just sayin...
Microsoft Backing Database Projects (Score:2)
Step 2: Microsoft writes a structured query database, it can hardly do any of these.
Step 3: "Rararara structured query sucks lets support some half-baked DB idea and as soon as there is a breakthrough buy it up."
Step 4: ???
Step 5: Profit!
Advocacy of NoSQL is a warning sign... (Score:2)
Shitty programmers who cannot be bothered to learn how relational databases work or seem to be completely oblivious to the fact that they are paid to create systems that not only serve the front end consumer user but also people on the backend business side would advocate NoSQL. If the product/service you are writing has anything to do with money, business users need to have information stored in a relational model that can be easily queried or extracted into a data cube for business analytics. This is why
Re: (Score:2)
Re: (Score:2)
And if your data doesn't fit in a relational database, how are you going to get it into a noSQL one? Writing serialized data in the value field?
Re: (Score:2)
Yeah that's great when your data fits the relational model.
What's your hypothetical data that can't be represented relationally? I haven't come across anything like that yet.
Re: (Score:2)
I have more data than you, so does Facebook. Try harder.
Sorry but I'm not falling for that. I have been working with relational databases for over a decade but I am not about to divulge who I work for.
Re: (Score:2)
Or maybe said "shitty" programmer:
- is writing a for-profit web app for his own company that consists of mostly programmers
- already knows in advance that the only queries he's ever going to make are those defined by the programmers, and that for his particular use case it's no disaster if newly introduced queries only work over new data
- already knows in advance that his data size will become several terabytes in several months and thus needs sharding
- does not want or have the resources to spend several m
Advocacy of SQL and relational model is a warning (Score:3)
Re: (Score:2)
You must have limited experience, relational model fits only set-based data well. There are plenty of hierarchical data structures for which the relational model is a terrible fit and give abysmal performance for both storage time and queries. I've seen this time and again in my three decades of working with relational databases. A client of mine has been working with medical AI systems for a few years, one early discover was relational model is absolutely an inferior representation for most knowledge base ontologies,
The relational model fits hierarchical data just fine. It's only the awkwardness of SQL that was holding you back or the particular implementation if queries were too slow. Is any of your experience based on a non-SQL relational language?
Re: (Score:2)
Re: (Score:2)
I know google is all fucked up they should run their search engine on oracle rac.
NoSql solutions are for extreme transaction rates on cheap or virtual hardware. It has nothing to do with not knowing how a database works. It has everything to do with how I am going to get sub second response with transaction rates in the 100s to thousands per second.
Not everything or every application fits into your perfect little view of the world.
Re: (Score:2)
Shitty programmers who cannot be bothered to learn how relational databases work or seem to be completely oblivious to the fact that they are paid to create systems that not only serve the front end consumer user but also people on the backend business side would advocate NoSQL. If the product/service you are writing has anything to do with money, business users need to have information stored in a relational model that can be easily queried or extracted into a data cube for business analytics. This is why you have data translation layers with data transformation objects (DTOs) in the first place to translate your object model into a relational model and back again.
If you work for a "for profit" company that deals with customer and sales data in any capacity then you need to have people competent people working who have at least a basic understanding of the relational model and transactions. If you work for one of those companies and are advocating NoSQL for data that the business needs for data mining or processing sales then you should either be reeducated or offered the door because you have forgotten who your actually work for.
It has nothing to do with "for profit" status. I work for a non-profit and work with a relational database all day. Observe how widely SQLite (which always has been a relational, SQL-based DBMS) is used, from Firefox to most smart phones. People who know how to use relational databases know they save a lot of development time which would otherwise have to be spent reinventing many wheels.
One area that needs work is language design, since SQL is far from ideal. I'm convinced that most of the complaints NoSQL
The Spec (Score:2)
http://www.unqlspec.org/display/UnQL/Home [unqlspec.org]
Wow took a lot of looking around!
Re: (Score:2)
This is a soft-sell way to get nosql databases into traditional IT situations, where familiarity with SQL will let current support and DBAs say "oh, it's like SQL, but it doesn't have joins. I can do that".
I always did like the sqlite docs, specifically the diagrams of the state machine for each statement.
Re: (Score:2)
This is a soft-sell way to get nosql databases into traditional IT situations, where familiarity with SQL will let current support and DBAs say "oh, it's like SQL, but it doesn't have joins. I can do that".
I always did like the sqlite docs, specifically the diagrams of the state machine for each statement.
If the DBAs think it's acceptable to lack joins, perhaps they should look for another job.
Re: (Score:2)
This is expected, did MS write anything well-structured in their history?
I'm fairly sure their legal dept. is well-structured. I could be wrong though.
Microsoft Legal Dept. (Score:2)
Re: (Score:2)
Re: (Score:2)
Well, call me crazy, but the idea of NoSQL was NOT USING SQL AT ALL... now we got a language that in FACT "could be considered a superset of SQL", ok now we have to learn SQL and MORE to use a NOsql set of data. Great but let's change the name of NoSql to something else because this is more st..p thing I heard in the last years... now what.. people is going to hand out meatballs at PETA meetings ....
Crazy? No. Ignorant. Yes. In essence "the idea of NoSQL was NOT USING SQL AT ALL" is simply not true. This has been mentioned for a while now, but apparently people can't seem to grasp it. NoSQL is a misnomer since the idea is not to move away from SQL but to provide data models alternative to Codd's relational model for a variety of reasons (high availability is just one of them.) I agree that the name needs to be changed, but I'd also say that Google is your friend.
Re: (Score:2)
UNQL, for a post-relational world. Nice. Meanwhile 90% [citation needed] of people working with databases can't even get relational databases right. Learning to run before learning to walk, anyone?
And we are moving into functional and functional-object-hybrid models of programming when the majority of programmers in 2011 cannot even do structured programming, and try every single way to break the Bohm-Jacopini Theorem using whatever du jour OOP language of the day. So what's your point?
If we had to wait for every moron code monkey to come up to speed, we would still be reading data off punch cards using a bastard mix of COBOL and mainframe assembly. Industrial and academic R&D and innovation f
Re: (Score:2)
1. Executing one subprogram, and then another subprogram (sequence)
2. Executing one of two subprograms according to the value of a boolean variable (selection)
Re: (Score:2)
The Structured Programming Theorem (redirected from Bohm-Jacopini Theorem) from Wikipedia states: The structured program theorem is a result in programming language theory. It states that every computable function can be implemented in a programming language that combines subprograms in only three specific ways. These three control structures are: 1. Executing one subprogram, and then another subprogram (sequence) 2. Executing one of two subprograms according to the value of a boolean variable (selection) 3. Executing a subprogram until a boolean variable is true (repetition) How does one exactly break this theorm?
It seems exaggeration and figures of speech to express the terrible state of affairs of the programming and software engineering practices cannot be performed lightly in what is supposed to be a "news for nerds" website. Let me break it down for you:
1. Hyperbole [wikipedia.org]:
is the use of exaggeration as a rhetorical device or figure of speech. It may be used to evoke strong feelings or to create a strong impression, but is not meant to be taken literally. Hyperboles are exaggerations to create emphasis or effect
2. Rhetoric:
3. Figurative speech [princeton.edu]:
S: (n) trope, figure of speech, figure, image (language used in a figurative or nonliteral sense)
With that cleared up, the figure of speech -slash- hyperbolic piece rhetoric below:
cannot even do structured programming, and try every single way to break the Bohm-Jacopini Theorem using whatever du jour OOP language of the day
is meant to serve as a grotesque, pejorative description of the equally grotesque situation of programmers - both the type who k
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
so much for UnQL.
Microsoft likes this? Is that why UnQL is pronounced uncool?