Power by Design
|
Select A Section home public service database mgr data access data modeler site notes |
Currently In This Section AxleBase Shortcomings ( Please Scroll Down ) |
Section Pages summary description design limits notable tests shortcomings nomenclature operation |
|
This is a legally copyrighted work,
Table Of Contents
__________________________________________________
The overwhelming reaction has been that AxleBase is too good to be true and is, therefore, impossible. Even those who see it demonstrated in person have trouble believing it. After decades of using many different big-name database managers, I understand. Therefore, this document makes AxleBase comparable to big-name brands by emphasizing its own problems and shortcomings.
__________________________________________________
General Shortcomings The system was built using Visual Basic version 5 (SP6). It was built without any system calls; i.e., no API calls to the operating system, which would have locked it into a single operating system. Where an API call was needed, a replacement was designed and coded. Regardless of the language used, it would need to be tranlated into the preferred language of the acquiring organization, extensive in-code comments were made. The design and coding of a translater app started, and its development progressed past the comment evaluator. Running the AxleBase code through it reports that the 53,000 lines of AxleBase code have over a quarter million words in comments.
General Shortcomings The AxleBase effort began with a computer science effort; i.e., its creator wanted to know what could be done in the constrained environment of the desktop computer. He would have preferred using Linux, but its maximum file size at that time was far smaller than that of Windows, so the latter was used. Windows 2000 worked well for years of development, so that is where it stayed. The developer was later interested in investigating larger databases, but was locked into the limit set by the earlier Windows maximum file size. He gave investigation into altering code to support larger files, but the earlier table size of 21.5 quintillion bytes was still beyond any known needs.
__________________________________________________
All other work ceases when a bug is discovered until it is fixed. Therefore, there are usually no known bugs. Bug Announcement In 2013 Recent development produced a major bug, and it will be retained to provide AxleBase with a known bug.
Bug Announcement In 2015 Great news! Another major bug popped up in late 2015 during testing of the super-system configuration.
__________________________________________________
These are intended, although were intended for years before development shutdosn. Maybe they are just not interesting enough to work on. Pending Parentheses :
SQL optimizer :
Clauses :
Math Operations :
Distinct :
Functions :
Pending Locks :
Disk management :
Concurrency :
__________________________________________________
A decision has not been reached on whether or not to add the following items. Column locks. Computed columns. Table constraints :
Table Size :
__________________________________________________
There is currently no intent to build these items into AxleBase. (However, most of the items that have disappeared from this section through the years were built accidentally because of my terrible memory. ) Intentional Abridgement
Intentional Abridgement AxleBase will not accept "joins" in the "where" clause or "wheres" in the "from" clause. Wheres must be in the where clause and joins must be in the from clause. Intentional Abridgement The modification of returned data has a miniscule priority since a host app can do it. For example, applying a date conversion to a column after it is selected can be done by the host. Intentional Abridgement The intent of AxleBase is the management and manipulation of unreasonably large magnitudes in all dimensions, which a query timeout would disrupt. However, AxleBase does allow user cancellation of running queries. Intentional Abridgement Century leap-seconds are not handled in date functions.
Intentional Abridgement AxleBase does support the ODBC protocol. But ODBC drivers should be written for the systems in which AxleBase will be embedded. However, this may be reconsidered to support the GUI front ends that are used in the AxleBase lab. They are beginning to require function duplications that could be alleviated by an ODBC driver.
Intentional Abridgement Because "CoreReader" can virtualize the big-name-brand databases, AxleBase was given the ability to drive CoreReader as an object. That allowed their live tables to be expressed inside AxleBase databases as AxleBase virtual tables. But I became so irritated by bugs in those big-name-brand systems that I removed their virtualization. Life is too short for that fight. Just thinking about fighting bugs encountered from billion dollar companies makes me want to cuss.
Intentional Abridgement The job construct has been implemented only to support one of AxleBase's advanced features. It will not be given the pseudo structured-programming abilities to which most DBAs are accustomed. Other systems refer to jobs as "Stored procedures".
Intentional Abridgement Adding triggers would be fairly easy, but it won't happen because that would be an excellent way to trash a trillion-row table.
Intentional Abridgement This has been known by various names through the years such as transaction logging and journaling with checkpointing. Its purpose is database restoration from a specified point. The objectives of AxleBase do not require journaling and they might actually be impaired by it. It could, for example, seriously degrade the speed of a very large database. It would be simple and a fun bit of programming, but is not seriously considered because of its negative impact on operations.
Intentional Abridgement Persistent consideration of this feature through the years continues to reveal the dangers to data and disruption to operations where views might be used in very large databases ( "VLDB"). A view is a query that is run against the involved tables every time that the view is referenced in the query, and can involve multiple views. AxleBase is designed for expensive databases containing very large and geographically distributed tables, and creating views with such objects could be disruptive or even catastrophic.
Intentional Abridgement This was investigated and rejected many years ago.
__________________________________________________
The following is the to-do list of things not completed when work on AxleBase stopped. Incomplete The only user descretionary lock that was functional when work stopped was the exclusive lock. See the "LockObject" command. Incomplete Need an error trap for a query structure mismatch. Need to raise an error when a user hands an axsys a logically erroneous join query that does not allow all rows of a base table for the query. That would be caused by seg/row assignment to all tables in the query, and by other situations. Incomplete Axsys needs this, but it has stopped working. Axsys needs to use some tables without seg/row range specification to do joins. But the nodes now bump into each other causing query timeouts in the nodes. Incomplete Queries are not using indices as well as possible. They analyze and execute each index independently and combine the results afterward, which is inefficient. A query should combine all analyses and execute them together for speed. But axlebase is already faster than anybody can believe, so why bother. (A hundred billion rows on old mechanical disks in three seconds...??!) Incomplete A means to review and retrieve audit history files had not been created when the AxleBase project was halted. Audit data security with inclusion of that data review makes that a non-simplistic upgrade. Incomplete Add the ability for the DBA to multi-type data columns. Maybe put it into the table definition. Then, allow a datatype specification in a query. That data type will be used by the system if that datatype is on file. But would this be useful in a production environment ? (I sometimes suspect that the scientist in me interferes with the practical side.) Incomplete The storage and management of the super system configuration is clunky. The "AxHandle GUI" helps, but it's clumsy. Incomplete I broke the virtual concatenation while developing. The cat table of concatenated tables is erroneous. Incomplete Virtualization for high speed builds could be done. Builds into multiple remote databases would increase the speed. Users of the master database could query them. But isn't that what clusters and the super-system are for? Unique rows could be a killer. Incomplete Did not complete the movement of the cluster concept into development. Incomplete ? They've started calling it unstructured data. Include the ability to index large blocks of text. BUT... Indexing large text blocks in a "VLT" might be nearly impossible and maybe counter-productive. However, a specialized text indexer could read each entire block of text and index every word in it, so i don't know. Actually..., it might be fun. Incomplete It might be a lot of help even for me. The driver would contain the remote socket interface and would store some variables like the axlebase address. Might be simple except for the socket programming. Hate the thought of getting back into windows sockets. Yuck. See also the "ODBC Drivers" sub-section in the "Operation Manual". Incomplete Might be easy to do. But it would add greatly to the system's complexity. So, would it be worth the effort? Incomplete I recall joining tables to themselves in the first years of development, and recall taking it out for some reason and forgot to put it back. Then one day I needed it. Dumb. Incomplete "AxHandle " is handling super-system returns in the development environment. Dataset harvesting by the AxHandle controller module is fragmented and complex, which puts a load on the user. After all, AxHandle is supposed to be a pattern for other systems. Incomplete The independence of the query nodes is good, so they will continue to be unaware of errors in each other. But that leaves AxHandle with the task of error handling in the development environment, and it's not currently
Besides, shouldn't all of that be handled inside the "AxleBase Error Protocol" sub-system. Either that or remove the error sub-system's "Super-System" error handler.
__________________________________________________ |
|
Web site and technology |
|
|
Web site is maintained with Notepad.
|
|