I'm investigating DocumentDBs, and I'm checking out the query side options. I know nothing has firmly established as of yet, but have a few questions I've yet seen fully answered.
Couchbase dropped out of UnQL? and then developed N1QL? Does this mean that they see N1QL as a more appropriate different query language? or does it extend what was set in UnQL? Was anything actually formally standardized?
Is anyone allowed to implement N1QL? Is it an open de-facto standard, vs. something patented in some way.
Regarding your first question...
N1QL is based on SQL, which is an ISO standard. Some of the language extensions like NEST/UNNEST and array comprehensions have been used and/or proposed elsewhere.
N1QL is not based on UnQL, but addresses some of the same needs with the advantage of being SQL.
Related
Different kind of software offer different amount of configuration/customization. Routers are one of the most configurable software systems I know of. I want to know how routers handle configurations - how they alter the code flow based on the configuration?
One obvious way is to use if..else clauses provided by most of the language(let's assume we are using C)
So is there any other programming method(or paradigm?)
Data-driven programming paradigm may be viable one. Configuration can be thought of one of the input source and so can be used to alter the code flow.
What I need to know is, is there any papers and references that I can use to enrich my understanding. Not just routers any kind of software. If the question seems to vague, let me know I will add more details.
I don't know anything about configuration of routers, but your question states you are interested in configuration for any kind of software, so the following might be of interest to you.
I am the author of Config4*, which provides C++ and Java parsers for a particular configuration syntax. I suggest you do the following. Skim Chapters 2 and 3 of the "Config4* Getting Started Guide" (HTML, PDF) to get an overview of the configuration syntax and API. Then take your time reading the "Config4* Practical Usage Guide" (HTML, PDF), which discusses the "how to" for a variety of different ways to use configuration. Although the discussion in that manual makes use of the Config4* syntax and API, the principles could be used with another syntax, for example, XML. If you focus on the principles discussed in that manual, rather than the syntax, then I suspect you will start to develop some insight into how a router handles its configuration.
I want to move away from socket.io to regular websockets to take advantage of the binary data transfers and get rid of the base64 encoding.
There seem to be two main websocket libraries for nodejs, both are on github:
Worlize/WebSocket-Node
einaros/ws
Both seem to be getting regular updates, both claim to be supporting the RFC-6455 standard.
Does anyone have experience with either or both of these who can share experience and/or make recommendations? Or does anyone know where I can find a recent comparison of them?
Further are there any plans for an official server side Websocket interface standard? These two libraries seem to have different API's. I did find this, but it is clearly for the client side only, and significantly newer than the date on the RFC standard.
I have been looking through every variation of Google search I can think of, and many related StackOverflow questions, but none seem to answer my question, and even the top Google results on the subject are several years out of date. Some related but insufficient StackOverflow threads include:
which-websocket-library-to-use-with-node-js
are-websockets-really-meant-to-be-handled-by-web-servers
web-sockets-server-side-implementation-for-nodejs
einaros/ws works great. However, Websocket-Node comes with routing support, which is quite handy for non-trivial implementations.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I was wondering what are the advantages of using Triple Stores over a relational database?
The viewpoint of the CTO of a company that extensively uses RDF Triplestores commercially:
Schema flexibility - it's possible to do the equivalent of a schema change to an RDF store live, and without any downtime, or redesign - it's not a free lunch, you need to be careful with how your software works, but it's a pretty easy thing to do.
More modern - RDF stores are typically queried over HTTP it's very easy to fit them into Service Architectures without hacky bridging solutions, or performance penalties. Also they handle internationalised content better than typical SQL databases - e.g. you can have multiple values in different languages.
Standardisation - the level of standardisation of implementations using RDF and SPARQL is much higher than SQL. It's possible to swap out one triplestore for another, though you have to be careful you're not stepping outside the standards. Moving data between stores is easy, as they all speak the same language.
Expressivity - it's much easier to model complex data in RDF than in SQL, and the query language makes it easier to do things like LEFT JOINs (called OPTIONAL in SPARQL). Conversely though, if your data is very tabular, then SQL is much easier.
Provenance - SPARQL lets you track where each piece of information came from, and you can store metadata about it, letting you easily do sophisticated queries, only taking into account data from certain sources, or with a certain trust level, on from some date range etc.
There are downsides though. SQL databases are generally much more mature, and have more features than typical RDF databases. Things like transactions are often much more crude, or non existent. Also, the cost per unit information stored in RDF v's SQL is noticeably higher. It's hard to generalise, but it can be significant if you have a lot of data - though at least in our case it's an overall benefit financially given the flexibility and power.
Both commenters are correct, especially since Semantic Web is not a database, it's a bit more general than that.
But I guess you might mean triple store, rather than Semantic Web in general, as triple store v. relational database is a somewhat more meaningful comparison. I'll preface the rest of my answer by noting that I'm not an expert in relational database systems, but I have a little bit of knowledge about triple stores.
Triple (or quad) stores are basically databases for data on the semantic web, particularly RDF. That's kind of where the similarity between triples stores & relational databases end. Both store data, both have query languages, both can be used to build applications on top of; so I guess if you squint your eyes, they're pretty similar. But the type of data each stores is quite different, so the two technologies optimize for different use cases and data structures, so they're not really interchangeable.
A lot of people have done work in overlaying a triples view of the world on top of a relational database, and that can work, and also will be slower than a system dedicated for storing and retrieving triples. Part of the problems is that SPARQL, the standard query language used by triple stores, can require a lot of self joins, something relational databases are not optimized for. If you look at benchmarks, such as SP2B, you can see that Oracle, which just overlays SPARQL support on its relational system, runs in the middle or at the back of the pack when compared with systems that more natively support RDF.
Of course, the RDF systems would probably get crushed by Oracle if they were doing SQL queries over relational data. But that's kind of the point, you pick the tool that's well suited for the application you want to build.
So if you're thinking about building a semantic web application, or just trying to get some familiarity in the area, I'd recommend ultimately going with a dedicated triple store.
I won't delve into reasoning and how that plays into query answering in triple stores, as that's yet another discussion, but it's another important distinction between relational systems and triple stores that do reasoning.
Some triplestores (Virtuoso, Jena SDB) are based on relational databases and simply provide an RDF / SPARQL interface. So to rephrase the question slighty, are triplestores built from the ground up as a triplestore more performant than those that aren't - #steve-harris definitely knows the answer to that ;) but I wager a yes.
Secondly, what features do triplestores have that RDBMS don't. The simple answer is support for SPARQL, RDF, OWL etc. (i.e the Semantic Web Technology stack) and to make it a fair fight, its better to define the value of SPARQL based on SPARQL 1.1 (it has considerably more features than 1.0). This provides support for federation (so so cool), property path expressions and entailment regimes along with an standards set of update protocols, graph management protocols (that SPARQL 1.0 didn't have and sorely lacked). Also #steve-harris points out that transactions are not part of the standard (can of worms) although many vendors provide non-standardised mechanisms for transactions (Virtuoso supports JDBC and Hibernate compliant connection pooling and management along with all the transactional features of Hibernate)
The big drawback in my mind is that not many triplestores support all of SPARQL 1.1 (since it is still not in recommendation) and this is where the real benefits lie.
Having said that, I am and always have been an advocate of substituting RDBMS with triplestores and platforms I deliver run entirely off triplestores (Volkswagen in my last role was an example of this), deprecating the need for RDBMS. An additional advantage is that Object to RDF mapping is more flexible and provides more options and flexibility than traditional ORM (also known as putting a square peg in a round hole).
Also you can still use a database but use RDF as a data exchange format which is very flexible.
I am developing an application on google map and checking out various options to store and retrieve spatial information within a bounding box.
Initially I thought MySql was not a good option, but after checking http://dev.mysql.com/doc/refman/5.6/en/spatial-analysis-functions.html and http://code.google.com/apis/maps/articles/phpsqlsearch.html, looks like I can use MySql and it does support my use cases.
I was also evaluating node.js and couchdb with geocouch.. With modules like socket.io, geo etc looks like this is also a good choice. check out the book "Getting Started with GEO, CouchDB, and Node.js". My application would be 1 page application and I do not foresee if I would require rdbms anytime in future.
i have also seen this - http://nodeguide.com/convincing_the_boss.html and this makes me little apprehensive about whether to go with node.js-geocouch....
If the architecture for your next apps reads like the cookbook of
NoSQL ingredients, please pause for a second and read this.
Yes, Redis, CouchDB, MongoDB, Riak, Casandra, etc. all look really
tempting, but so did that red apple Eve couldn't resist. If you're
already taking a technological risk with using node.js, you shouldn't
multiply it with more technology you probably don't fully understand
yet.
Sure, there are legitimate use cases for choosing a document oriented
database. But if you are trying to build a business on top of your
software, sticking to conservative database technology (like postgres
or mysql) might just outweigh the benefits of satisfying your inner
nerd and impressing your friends.
What is your opinion ?
GeoCouch sounds like a good solution in your case. If you want to have an easy installation, you can have a look at Couchbase Single Server, which is basically a CouchDB with GeoCouch included (check out the Developer Preview for 2.0.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
Is there any site available online for verifying the syntax which conforms to multiple databases?
For example: If I have a SQL statement with a 'usage' keyword, then the site should throw me an error saying that 'usage' keyword is reserved in MYSQL?
You could try a formatter like this
They will always be limited because they don't (and can't) know what user defined functions you may have defined in your database (or which built-in functions you have or don't have access to).
You could also look at ANTLR (but that would be an offline solution)
Have you tried http://www.dpriver.com/pp/sqlformat.htm?
I haven't ever seen such a thing, but there is this dev tool that includes a syntax checker for oracle, mysql, db2, and sql server... http://www.sqlparser.com/index.php
However this seems to be just the library. You'd need to build an app to leverage the parser to do what you want. And the Enterprise edition that includes all of the databases would cost you $450... ouch!
EDIT:
And, after saying that - it looks like someone might already have done what you want using that library: http://www.wangz.net/cgi-bin/pp/gsqlparser/sqlpp/sqlformat.tpl
The online tool doesn't automatically check against each DB though, you need to run each manually. Nor can I say how good it is at checking the syntax. That you'd need to investigate yourself.
Only know about this. Not sure how well does it against MySQL http://developer.mimer.se/validator/
I don't know of any such, and my experience is that it doesn't currently exist. Most are side by side comparisons of two databases. That information requires experts in all the databases encountered, which isn't common. Versions depend too, to know what is supported.
ANSI functions are making strides to ensure syntax is supported across databases, but it's dependent on vendors implementing the spec. And to date, they aren't implementing the entire ANSI spec at a time.
But you can crowd source on sites like this one by asking specific questions and including the databases involved and the versions used.
I am willing to bet some of my reputation that there is no such thing.
Partially because if you are worried about cross-platform SQL compatibility, your best bet in turn is to abstract your database code with some API or ORM tool that handles these things for you, and is well supported, so will deal with newer database versions as they come out.
Exact kind of API available to you will be dependent on your programming language/platform. For example, PHP has Pear:DB and others, I personally have found quite nice Python's ORM features implemented in Django framework. I presume there should be some of these things available on other platforms as well.