CryptoGateway 综合文本
文境: [Commercial][Archymeta Information Technologies]
[Technologies][White Paper for the File System Database]
The Current State of Affairs
4) Extended Language Derived from SQL as sub-DSL
last-scan: Sat, 01 Dec 2012 02:35:31 GMT (9290b8ffe7116b6e...)

Instead of meta-language SQL is a DSL for querying relational data sets. SQL is can be applied to any relational data. To apply it to a particular relational database instance, the user must has the knowledge for the structure of the database and add this knowledge into the expressions (sentences) targeting the said database instance. He/she could make mistakes by misuse the knowledge, for example the name of a table is not written right. The mistake will not be found until the expression is executed against the database engine during run-time, which may result in unwanted effects, say, causing a disaster.

last-scan: Sat, 01 Dec 2012 02:35:31 GMT (e920188e479c2052...)

Following the instruction above, one can see that DSL can also have multiple levels. Now suppose one can develop a sub-class of SQL language that targets a specific database instance, then the structural knowledge can be built into the syntax of the language and will be enforced by the code “generator”, the “compiler” or “interpreter” of the language, the potential of a disaster can be systematically eliminated from the very beginning. The system could also runs faster since no-time has to be wasted on checking query expression conform the underline structure of the target database instance, e.g. making sure that a named table does exist, at runtime.

last-scan: Sat, 01 Dec 2012 02:35:31 GMT (e0d2c7e4695d3a45...)

Experienced developer may think that developing a general language like SQL is already hard enough (since the more generic the language, the less information it contains, and therefore the simpler it becomes to produce a compiler with regard to information encoding aspect of things. Of course general languages are most likely harder to produce since they are usually finer in implementation and must consider far more application scenarios than specialized ones), produce and maintain a DSL that must be synchronized with an evolving database instance is something not worth doing, especially when the database instance has many tens or hundreds of tables. The enormous information encoding and synchronization task could overwhelm even a talented developer, easily.

last-scan: Sat, 01 Dec 2012 02:35:31 GMT (2f3573bff923a601...)

This is indeed the case using current tools available on the market. In many sense, this is no longer true in our system.