Is there any schema-less dbms that support SQL query syntax? RDBMSs support sql languages, noSQL DBMSs are schema less. But is there any schema less that support a query language similar to sql?
I found http://www.couchbase.com/communities/n1ql
N1QL presents easy and familiar abstractions to quickly develop scalable applications that work with next generation database systems. It allows for filter expressions, aggregate expressions and many other features to build a rich application. Go ahead and give N1QL a spin!
also: http://crlog.info/2011/06/13/cassandra-query-language-cql-v1-0-0-updated/
Djondb (http://djondb.com) supports a language similar to SQL called DQL (document query language), although it's similar in some ways you'll find that most of these languages are oriented to documents rather than columns and rows, hope this help you on your search
Related
I know AgensGraph supports ANSI SQL and Cypher language both.
If so, can I use ANSI SQL for graph data? and the opposite too.
What I want to know is, should I choose and use the language for each data?
Agensgraph doesn't appear to explicitly say you can't use SQL on graphs or Cypher on tables, but if you look at their architecture, the relational and graph databases are almost completely separate, only sharing the transaction/cache layers.
So only Cypher can access graphs, and only ANSI SQL can access tables; So the only way to cross reference both is to use the hybrid format.
Further reading: Docs
I'm looking for good SQL parser. One that will work with subselects, non-select queries, CTE, window functions and other legal SQL elements.
Result would be some kind of abstract syntax tree, that I could later on work on.
Language is mostly irrelevant, as I am willing to learn new language just to use the library, if it exists.
I know that it is technically possible to extract parser from some open source database, but it's far from easy (at least for the parser of PostgreSQL which is what I need).
There's a non-validating SQL parser in Python: python-sqlparse. The tokens are exposed as objects. I doubt if they support "other legal SQL statements", window functions, and the like though as those are controlled by vendor specific grammars and no vendor is technically fully compliant with SQL standards.
Um (knowing that you're willing to learn a new language), why would you need to work on the syntax tree? If you need some magic in dealing with the database, probably you don't need to reinvent the wheel: Python got a fantastic database toolkit - SQL ALchemy.
You can google "sql parser". This is the one that listed: General SQL Parser Here are some highlighted features listed on official website:
Offline SQL syntax check
Highly customizable SQL formatter
In-depth analysis of SQL script
Fully access to SQL query parse tree
Custom SQL engine for various databases
Major programming language support
It's a commercial SQL library.
Our DMS Software Reengineering Toolkit has PL/SQL and ANSI SQL 2011 full parsers (to ASTs) and prettyprinters (ASTs back to valid text). Neither of these are PostGres SQL, but DMS has a dialect mechanism that enables one to relatively easily build a dialect from a base grammar, by revising just some of the grammar rules and retaining the rest. Doing this from the SQL 2011 grammar seems like a practical way to tackle the problem.
DMS also offers facilities to access/traverse/modify the ASTs, both procedurally and in terms of surface-syntax patterns and transformations. Think of this as "life beyond parsing".
I'm looking for a SQL Implementation (and its Editor) that can be used for translating it to many other(s) SQL Languages.
For example, when i code in that SQL Language to script file(s), and then i translate to other(s) SQL Language script file(s) (for ex: MS SQL's , MySQL's , ...).
If you're sure to use only ANSI SQL to construct your scripts, you should be good to go.
I agree with #Justin Niessner: all SQL vendors pay attention to the SQL Standards, notably core SQL-92. To take SQL Server as an example, although they find Sybase legacy code is tricky to deprecate they are not afraid to do so and entirely new features (e.g. MERGE in MSSQL2008) tend to extend their Standard SQL equivalents, rather than reinventing the wheel.
For a product that has good Standards compliance, take a look at Mimer
Here at Mimer Information Technology, we pride ourselves on conforming
to the SQL standard and we play an active role in the Database
Languages standardization group which determines exactly what is SQL
standard.
Mimer also provide extremely useful SQL validators for SQL-92, SQL-99 and SQL:2003 respectively.
I've been researching the same thing a while ago. What I've found is that there is a project liquibase. It is aimed at change tracking but also converting between different DBMS. You can download source code and see different datatypes conversions across databases. Source at github browse for java files there, probably you'll find something helpful
If all you want are basic operations, these are fairly universal. For instance:
SELECT
INSERT
DELETE
UPDATE
FROM
WHERE
JOIN
...are all at the most basic level the same across implementations.
However, the more complicated your scripts get, the more difficult it becomes to make them "universal". Things like aggregation, subqueries, cursors, while loops, functions, indexes, constraints, temp tables, variables, string manipulation, window operations etc. are all pretty much database-specific.
Some of these do have "universal" equivalents but the more generic you make your code the worse it will perform.
I've been searching for half an hour and can't find any resources stating what level of the SQL ANSI standard is supported on various database engines.
It looks like some level of support is provided by most engines, but I'd like to know exactly what level is officially supported.
I'm primarily interested in MySQL, PostgreSQL, SQL Server, and Oracle.
EDIT: PostgreSQL has a great page on compliance, exactly what I was looking for regarding the other engines: http://www.postgresql.org/docs/current/interactive/features.html
these might help a little:
Comparison of different SQL implementations
wikipedia - Comparison of relational database management systems
wikipedia - SQL - Standardization
The question of "which level of the standard" is too simple.
There are portions of the standard that are implemented by no engine at all, e.g. CREATE ASSERTION.
For that reason, it might be better to speak of "percentage of standard features supported" for each individual engine. But the vendors will be very reluctant to publish such measurements themselves.
The PostgreSQL manual has for all SQL statements a compatibility section.
According to the HSQLDB manual, it is the most standards compliant RDBMS.
Almost all syntactic features of SQL-92 up to Advanced Level are supported
SQL:2008 core and many optional features of this standard
Firebird 3 sql standard conformance page
My team is looking into geospatial features offered by different database platforms.
Are all of the implementations database specific, or is there a ANSI SQL standard, or similar type of standard, which is being offered, or will be offered in the future?
I ask, because I would like the implemented code to be as database agnostic as possible (our project is written to be ANSI SQL standard).
Is there any known plan for standardization of this functionality in the future?
Currently, there are more than one specifications followed by popular proprietary and open source implementations of spatial databases:
The OpenGIS - Simple Features for SQL
ISO SQL Multimedia Specification for Spatial - ISO/IEC 13249-3:2006 - Information technology -- Database languages -- SQL multimedia and application packages -- Part 3: Spatial
PostGIS, Oracle, Microsoft SQL Server and to some limited degree MySQL, all the databases implement the standard interfaces to manipulate spatial data. However, in spite of this fairly standardized features, all databases usually differ on simple SQL level what may make the database-agnostic implementation of your solution tricky. You likely need to survey the features you are interested and compare what various vendors provide.
For example GIS extensions for MySQL and for PostgreSQL both follow OpenGIS "Simple Features Specification for SQL" standard.
I haven't tried it, but Google tells me FDO is "an open-source API for manipulating, defining and analyzing geospatial information regardless of where it is stored". It's listed on osgeo.org - a point in its favour in my opinion.
There are providers for MySQL & Oracle. Disappointingly though SQL Server and Postgis aren't listed on the FDO providers page.
The only standard I know of is http://www.opengeospatial.org/standards/sfs and I don't know how well all the spatial database extensions implement it.
there are a number of geo-databases which are accessible with hibernate spatial
Oracle10g
Postgresql
MySQL
using an abtraction layer like hibernate is a good idea anyways, if you plan to write a database agnostic application. hibernatespatial fills this gap for geo features.