From the concept that applications are 'living' and always changing and growing, the data requirements to that application are also living. Within that context, we don't have a magic crystal ball that will tell us every future data structure that an application will require. When an app requires changes to it's data model, the database tends to becomes a chain that ties down the app to it's limited/difficult-to-change data structure. On top of the structure limitations, there are also limitations on the querying abilities provided by the same database (e.g. which fields to index, etc).
Not true with SchemafreeSQL, wherein the Developer can immediately start saving data in any structure
and alter that structure at runtime without missing a beat.
SchemafreeSQL also allows 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.
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.
With SchemafreeSQL, you can query deeply across complex structures via a simple join-free SQL syntax called SFQL (Schema-Free Query Language).
Example:
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.)
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.
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')
SchemafreeSQL delivers fast indexed queries without index configuration AND at the same time maintains predictable insert speeds by avoiding myriad composite indexes.
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 which we'll refer to as the "Index Permutation Limitation".
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 permutations 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 you wanted to cover every 5-column index permutation across 50 columns, there would be over 254 million indexes to create!
Fortunately, SchemafreeSQL removes this problem from your plate. With SchemafreeSQL, you get indexing for free. Well, nothing's free of course, but this is as "free" (i.e. cost vs benefit) as is practically possible. Not even a second of your time will be wasted on index design or optimization. A single dedicated-compound-index may be faster on it's own, but SchemafreeSQL can give you near single-dedicated-compound-index speed across ALL of those 254+ million possible index permutations (from the choose 5 out of 50 problem). 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 composite indexes, but 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.