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 SchemafreeDB, wherein the web developer can immediately start saving data in any structure and alter that structure at runtime without missing a beat.
SchemafreeDB 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.

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

See the database depth chart.

SchemafreeDB is NOT NoSQL. On the contrary, SchemafreeDB 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.

• NOT a pure SQL database SchemafreeDB 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 SchemafreeDB, 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, SchemafreeDB allows arbitrary key-value relationships just as key-value stores do, but SchemafreeDB 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 SchemafreeDB data relationships are handled at the database level. Map-reduce SQL layers are implemented at higher and much slower levels.
• NOT a ORM-layer SchemafreeDB 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. SchemafreeDB's simple-yet-powerful SFQL delivers consistent developer productivity.

No. The SchemafreeDB API is implemented as a simple JSON-over-HTTP API which is conistent across all platforms.
The core JSON itself is very simple and extensible, leaving room for future SchemafreeDB features without disturbing the core API JSON structure.

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.

With SchemafreeDB, 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.

With SchemafreeDB, 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 jquery 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.

With SchemafreeDB, you can query deeply across complex structures via a simple join-free SQL syntax called SFQL (Schema-Free Query Language). e.g: 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 SchemafreeDB, but instead using standard SQL and joins:

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:
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:

Unbounded queries allow you to query outside the confines of your data structure and are example of how SchemafreeDB 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. And if you had even more occurances of the attribute 'city' deeply spread throughout your database, it would require more than 2 queries in other databases.

Additionally, SchemafreeDB 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.)

You can store as many blob and large-text attributes per object as you like. SchemafreeDB 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.

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')

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.

SchemafreeDB 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, SchemafreeDB removes this problem from your plate. With SchemafreeDB, 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. SchemafreeDB provides you with the benefits of vast numbers of (hypotheical) composite indexes without the downfalls.

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.