SchemafreeSQL

What is "Database Depth"?

Database Depth is a measurement of two attributes very important to Web Applications: "Data Structure Flexibility" and "Querying Ability".

It is impossible to know up-front the data structure that your web application will require, yet developers are asked to create data models in advance. Then, when changes are required to that model - and they always are for any 'living' application - the developer's database often becomes a chain that ties them to limited structure possibilities or difficult-to-change data structures. And on top of the structure limitations, there are inevitably limitations on the querying abilities provided by the same database.

Not true with SchemafreeSQL, wherein the web developer can immediately start saving data in any structure and alter that structure at runtime without missing a beat.
SchemafreeSQL also allows Web developers to fearlessly query their data without limitations and often in manners never thought possible. Complex ad-hoc queries can be created at runtime without the need to manage indexes and without the need to develop inefficient methods that require layers of back-and-forth trips to the database.

SchemafreeSQL scores high in both Data Structure Flexibility and Querying Ability, giving it a high Database Depth score compared to other database solutions.

Is this just another NoSQL solution?

SchemafreeSQL is NOT NoSQL. On the contrary, SchemafreeSQL allows powerful SQL statements through it's enhanced SFQL query language which provides join-like operations with simple dot-notated relations. This allows web developers to create complex queries across complex relationships at run-time, but with greater ease than either NoSQL or straight SQL.

SchemafreeSQL is also:

NOT a pure SQL database SchemafreeSQL eliminates the need to define zombie schemas and indexes and write JOINs.
NOT a document-based database
Several document-based database systems claim to be schemaless, yet when your data demands cross-document relations (esp. many-to-many), something ugly rears its head which usually ends with you performing multiple queries and relating (or JOINing) data by hand. This essentially forces the work away from the locality and fast speed of the database level, and up towards the remote and slow speed of the client-to-database connection. The difference in speed is akin to the difference between registers and RAM, or between RAM and Disk.
The resultant design pattern often ends up a mirror of what you would have done in any standard SQL database, but without the low level optimizations that a SQL database brings to such a pattern.

Additionally, with a non-native design pattern now in place to deal with your data relationships, concurrency issues may begin to surface.
In SchemafreeSQL, your data relationship possibilities are essentially unbounded; yet consistent in both design patterns, access patterns and performance.
NOT a key-value database At the simplest level, SchemafreeSQL allows arbitrary key-value relationships just as key-value stores do, but SchemafreeSQL also allows the values to be objects themselves (no need for embedded 'lists') and provides powerful-yet-simple querying via SFQL.
NOT a SQL-layer on top of a map-reduce database SchemafreeSQL data relationships are handled at the database level. Map-reduce SQL layers are implemented at higher and much slower levels.
NOT a ORM-layer SchemafreeSQL data objects, although represented with the simplicity of ORM-styled dot-notated relationships, are completely independent of your programs' in-memory objects. Object-Relation-Mapping layers, on the other hand, create an impedance-mismatch between in-memory objects and database objects.
NOT a vector-based database Although powerful, navigating vector-based databases can become complcated. SchemafreeSQL's simple-yet-powerful SFQL delivers consistent developer productivity.

Is there a complicated API?

No. The SchemafreeSQL API is implemented as a simple JSON-over-HTTP API which is consistent across all platforms.
Language-specific APIs which implement the JSON API can be implemented. We have developed a reference version of such an API in go which is freely available for inspection and use.
The core JSON itself is very simple and extensible, leaving room for future SchemafreeSQL features without disturbing the core API JSON structure.

Is there anything to install?

The only requirements are that your platform support HTTP networking and JSON, and both libraries are either built-in or installable within most platforms. See: json.org.

What are "free-form data structures" and does this help me as a web developer?

With SchemafreeSQL, there are no schemas to create and manage, EVER. Simply start inserting data - including relationships between data (i.e. sub-objects) - as your application requires, in real-time. This enables new classes of applications with user-defined data sets, flexibility of design throughout an application's lifecycle, ease of migration and rapid prototyping.

I can create complex structures and relationships now. How is SchemafreeSQL different in this respect?

With SchemafreeSQL, you can store and query complex structures and establish complex relations between those structures at runtime. Plus, you can do all this without creating fixed schemas. You can also import/export complete or partial graphs in either a simple add-style or a fully-referenced, non-duplicated update-style. This means that you can easily create custom data-update routines on subsets of your data (i.e. contact-list syncronization) with a simple command.

What is "join-free SQL" and why is this a good thing?

With SchemafreeSQL, you can query deeply across complex structures via a simple join-free SQL syntax called SFQL (Schema-Free Query Language).
Example:

SELECT $person.oid WHERE $s:company.person.address.city='Rochester' AND $n:company.person.income>50000

The above query and structure naturally supports cases of both one-to-one, one-to-many and many-to-many relationships (e.g. companies to persons, or persons to addresses) without requiring extra lookup tables for the many-to-many relationships. This simplicity gives you new efficiencies when working with complex or deep data strutures, thus increasing your overall productivity as a developer.

Here is a representative example of the joins required if you were not using SchemafreeSQL, but instead using standard SQL and joins:

SELECT person.oid
FROM company
INNER JOIN person ON person.companyId = company.id
INNER JOIN address ON address.id = person.addressId
WHERE address.city='Rochester' AND person.income>50000

And if the address-to-person relationship was a many-to-many (e.g. if you wanted to allow your structure to support persons who share a single address object without duplicating address objects - such as a husband and wife) then standard SQL would require:

SELECT person.oid
FROM company
INNER JOIN person ON person.companyId = company.id
INNER JOIN personAddress ON personAddress.personId = person.id
INNER JOIN address ON address.id = personAddress.addressId
WHERE address.city='Rochester' AND person.income>50000

And if the person-to-company relationship was also a many-to-many (e.g. if you wanted to allow your structure to support people who work for multiple companies without duplicating person objects) then standard SQL would require:

SELECT person.oid
FROM company
INNER JOIN companyPerson ON companyPerson.companyId = company.id
INNER JOIN person ON person.id = companyPerson.personId
INNER JOIN personAddress ON personAddress.personId = person.id
INNER JOIN address ON address.id = personAddress.addressId
WHERE address.city='Rochester' AND person.income>50000

What is "unbounded, cross-relationship global querying"?

Unbounded queries allow you to query outside the confines of your data structure and are an example of how SchemafreeSQL can "expand your application possibilities."

For instance, you can issue a unbounded query (SELECT $oid WHERE $s:city='Rochester') against a database that contains vendor.address.city objects and promotion.city objects and the query will return the oids of both matching vendor.address objects and matching promotion objects. This single query takes the place of what would normally require 2 queries (whether executed in series or with a UNION).

Additionally, SchemafreeSQL global queries can be optionally bounded to any select number of parents. For example you could globally query (WHERE $s:person.address.city) which would limit your query to person.address objects no matter where they occur in your database (e.g. under employees, or under family, etc.)

Can large text attributes and BLOBs be stored?

You can store as many blob and large-text attributes per object as you like. SchemafreeSQL does not place an extra constraint on the maximum number of blob or large-text attributes per object.

A feature currently being worked on is the ability to store and retrieve specific byte-ranges against BLOBs. This feature will enable you to work with binary data in a more natural and efficient manner than the typical "all-or-nothing" of most databases. This feature will allow you to get and set bytes the way your filesystem allows you to, at a low level.

Is full-text search available?

This is being worked on. Below is an explanation of what you can expect when it is completed.

Selectively index individual data attributes. Selectively query full-text attributes in full combination with your standard SQL queries. (e.g. SELECT $s:firstname, $s:lastname WHERE $s:state='NY' AND $workHistory.word()='lisp' AND $workHistory.word()='sql')

Are any MVCC-like operations available?

Currently available is a MVCC-like option available in conjuction with the 'remove' sub-command. For example, you can execute a delayed remove which immediately removes the data from future query results, but at the same time is capable of being recalled within the time-window you specify (e.g. 1 hour) Useful when designing "undo" features for clients.
Additional MVCC-like options are planned for the other 'modify' sub-commands.

What is meant by "Optimization-free"

SchemafreeSQL delivers fast index-like queries without index configuration AND at the same time delivers inserts at fast no-index speeds.

As applications grow, the diversity of queries grow. To maintain acceptable query performance, it is common practice to create new indexes on both single columns and combinations of columns. However, when trying to create a composite index for every possible combination of queried column sets, you run into a serious problem…

For example, suppose you had just 10 columns on a table but user demands kept growing as to what columns they wanted to filter against. Even if the users only filtered against 3 of the 10 columns, there are 720 possible combinations of 3 column sets (10!/(10-3)!). Of course, you won't get close to making that many indexes anyway, as SQL databases have a hard (and practical) limit on how many you can create and/or how large your indexes can be. MyISAM for instance, has a limit of 64 indexes per table, and InnoDB has restrictions on the number of bytes per index (3072 bytes or about 768 chars). But regardless of the database limits, if you actually had 720 indexes on a table, INSERT speed would most likely grind to a halt. And this is only a simplistic scenario. If your table had 50 columns, there would be over 5 million four column combinations!

Fortunately, SchemafreeSQL removes this problem from your plate. With SchemafreeSQL, you get indexing for free. Not even a second of your time will be wasted on index design or optimization. And in case you are worrying - no, we are NOT creating composite indexes on demand in reaction to your queries. SchemafreeSQL provides you with the benefits of vast numbers of (hypotheical) composite indexes without the downfalls.

What is date math and date shortcuts?

Date math is both a convenience feature and application enhancement/power feature. It allows an application or an application's end-users to greatly simplify and extend the way date values are input.
It is available for use within the 'modify' command against 'date' and 'time' type attributes.

For Example: "+1M +5d" would calculate as 1 month and 5 days from now.
"1/1/2020 -5m" would calculate as 5 minutes before midnight Dec 31st 2019.
Year, Month, Week, Day, Hour, Minute and Second math is available for use.