Survey

About the project NewSQL

The Language

NewSQL is a new database access language to be developed. Targets are:

NewSQL is a replacement for SQL. It is not an extension or subset of SQL, not an object database language, and not an Object-Relation mapping tool.

The Translator

A translator from NewSQL to the various dialects of SQL will be implemented. This is done in the form of a JDBC driver. Features of the translator are:

Related Project LDBC

LDBC (Liberty DataBase Connectivity) is a JDBC driver that provides vendor-independent database access. LDBC is based on ANSI-SQL and JDBC.

See also: http://ldbc.sourceforge.net

About the Author

NewSQL is the diploma work of Thomas Müller, Class I-99-1, Hochschule für Technik und Architektur ( http://www.hta-be.bfh.ch) , Bern, Switzerland. Thomas Müller is the original author of Hypersonic SQL (an open source SQL database written in Java, see also http://hsqldb.sourceforge.net

Questions on Database Usage

SQL (Structured Query Language)

don't know heard about know know well Topic
insert, update, delete, select
order by
subqueries (nested queries)
exists, in(.,.,...)
count(*), min(x), max(x) or sum(x)
group by
having
distinct
create table
create index
referential integrity
referential integrity
sequences (Oracle style)
transaction support (commit, rollback)
2-phase-commit (distributed transactions)

Other Database Access Languages

don't know heard about know know well Topic
OQL (object query language)
relational algebra
other:

How I use (or plan to use) SQL

don't know heard about I did some I did a lot Topic
I run ad-hoc statements
I write an application that uses SQL
I use tools like MS Access
I use object-relation mapping tools
other:

Databases

don't know heard about know know well Topic
Oracle
Microsoft SQL Server
MySQL
PostgreSQL
Microsoft Access
IBM DB2
other:
other:

Programming Languages and APIs

don't know heard about know know well Topic
Java
JDBC API
C, C++
Visual Basic
C#
LDBC (cross database SQL translator)
object-relation mapping tools:
JDO
other:

Questions on NewSQL

Identifiers

Identifiers are table names, column names and so on. In SQL, they are case insensitive. In NewSQL, identifiers should be:

Case sensitive like Java, C, C++, C#,...
Case insensitive like in SQL, COBOL
No opinion or I can't answer this question

Quoted Names

SQL supports a construct called 'quoted identifiers' where identifiers can include spaces and special characters (and in this case, the identifiers are case sensitive). Quoted identifiers are not supported in any other programming language.

Quoted names should be supported
There is no need to support quoted names
No opinion or I can't answer this question

NULL handling

SQL supports NULL values, however the NULL behavior is different than one would normally expect. In SQL, NULL is not a value; and when comparing NULL with something else results in NULL (not FALSE and not TRUE: NULL). That means other than regular programming languages, SQL knows not only TRUE or FALSE as results for comparison, but also NULL. Some examples:

I like these NULL rules
I think these NULL rules are confusing and should be simplified
No opinion or I can't answer this question

Different syntax for different databases

Each database vendor implements his own flavor of SQL. The following SQL statement needs to be translated to other databases:

I didn't know that
I know about incompatibilities, but never myself had problems
I already ran into some problems / incompatibilities
I did work on a project that involved support for multiple databases. Please specify project and databases:
     

Autoincrement columns

ANSI SQL does not support autoincrement columns (sometimes called identity column, sequences or automatic surrogate keys). However, most databases support autoincrement columns in some way: For example, in MS SQL Server they are called identity columns. Oracle does not support this kind of columns, but Oracle supports sequences - this is something like a user defined function that returns another number for each call.

Autoincrement columns should be supported
Oracle style sequences should be supported
No opinion or I can't answer this question

Strings (text data, varchar)

In the SQL standard, the user must set the maximum size (for example, 60 characters) for string columns when the table is created. Often, it turns out later on that the size is too small, and must be changed.

Modern programming languages like Java or C++ don't have size restrictions for strings. The size restriction in SQL probably originates from the early days of computing: COBOL also knows size restrictions. However, in modern databases, variable size strings are not slower than fixed size strings.

Each string should have a size limitation (like in COBOL)
Strings should not have size restrictions like in Java, C++,...
No opinion or I can't answer this question

Style

Certain features are supported by all databases, but in a slightly different way. An example is comparison syntax: in Java, the comparison operators are: ==, !=, <=, >=, <, >. In SQL, they are: =, <>, <=, >=. There are language details that define the language style, like the usage of brackets (), [], {} and uppercase / lowercase usage. I like the NewSQL to look like:

Java, C#, Perl, Python
SQL, COBOL
Other:

Grammar Examples

In the following examples, please note what you like, and describe things you don't like. You can also make remarks if you like.

SQL:

CREATE TABLE TEST(ID INT PRIMARY KEY, NAME VARCHAR(255))
INSERT INTO TEST VALUES(1,'Hello')
SELECT * FROM TEST
SELECT T1.ID,T2.NAME FROM TEST T1, TEST T2 WHERE T.ID=T2.ID
UPDATE TEST SET NAME='Hi' WHERE ID=1
DELETE FROM TEST WHERE ID=1
DROP TABLE TEST

Java Style:

test=new table(int id, string name, key(id))
test.add(1,"Hello")
test.get()
t1=test; t2=test; t1.join(t2[t1.id==t2.id]).get(t1.id,t2.name)
test[id==1].set(name="Hi")
test[id==1].delete()
test.drop()

Simplified SQL:

create table test(id int, name string, primary key(id))
insert test (1,'Hello')
select test
select t1:test join t2:test on t1.id==t2.id get t1.id, t2.name
update test set id=1 where name=='Hi'
delete test where id==1
drop test

Which grammar do you like most?

SQL
Java Style
Simplified SQL
No opinion or I can't answer this question

Joins

In many cases, it is required to select data from multiple tables at the same time, because the data is distributed in multiple tables. In SQL, explicit joins must be used to do that.

Example:

SELECT Order.Price, Address.Name FROM Order, Address
WHERE Order.AddressId=Address.Id

An alternative syntax for this query is:

SELECT O.Price, A.Name FROM Order O
INNER JOIN Address A ON O.AddressId=A.Id

Object databases support automatic navigation that makes (most) joins unnecessary. In OQL (object query language), the statement could look like this:

SELECT O.Price, O.Address.Name FROM Order O

NewSQL should support automatic navigation similar to OQL
Explicit joins like in SQL are enough
No opinion or I can't answer this question

Exception handling

Current databases throw different kinds of exceptions for the same error, for example for syntax error. Therefore cross platform applications can not rely on the exception codes.

NewSQL should define exception codes for the most important errors
Exception codes don't need to the same across databases (like in SQL)
No opinion or I can't answer this question

Miscellaneous Questions

NewSQL will be good and useful (I hope)
A new database programming language is not required; SQL is ok
I don't need SQL, because I use object-relation mappings
It is a problem that no big company supports NewSQL

Remarks:

Importance

How important are this features (Very: very important; Not: not important):

Very 4 3 2 Not Don't know
update, insert, delete, select
referential integrity
stored procedures
build in functions
user defined functions
select with join
ordering
grouping
distinct
outer joins
having
subqueries
views
transaction support
savepoints
2-phase-commit (distributed transactions)
type casting
insert from a select
access rights: user names, password
access rights: roles
table level access restrictions
fine grained restrictions (column level)
insert: default values

Contact Information (optional)

The contact information is purely optional. If filled out, it will only be used in context of this survey. It will be deleted after the survey.

Name:

E-Mail: