Multi Paradigm Database Questions

Based on material from MultiParadigmDatabaseCriticism

[parts below are still under construction]

Re: "I see no language specification"

I see little need for that. It would use SQL, with additions to deal with dynamic types as shown at [link to be inserted], but I'm not dictating a dialect of SQL at this point. One can "create" schemas just by inserting and updating data, at least in "on the fly creation" default mode.

   INSERT INTO my_table (a, b, c) values (1, 2, "foo")

In default mode, this itself creates table called "my_table" with 3 columns, if they don't already exist.

   UPDATE my_table SET d=3 WHERE a=1   // or "a #= 1" to clarify numeric compare

This would "create" a new column "d". I put "create" in quotes because it's more like a virtual column, as described at [link to be inserted]. An empty dynamic column is indistinguishable from a non-existent dynamic column such that "exists" takes on a different meaning than traditional RDBMS.

And restrictions can be added as desired to require explicit table and/or column declaration and/or types. A database-specific setting flag would be given in a config file or control panel to set table creation to require an explicit creation in they way current RDBMS do.

That's a start. Until you described this, how would we know? Your "SQL, with additions" is sufficiently different from SQL to warrant a description, otherwise how can we know what you have in mind?

Re: "no interface design"

Command-line SQL, and perhaps DDL. If somebody wants to create a GUI wrapper around the command line, that's fine, but that's not "the core".

Until you said so, how would we know?

• For one, I never mentioned a GUI interface anywhere, and GUI interfaces are usually add-ons in the history of existing RDBMS. I believe based on both of these facts it's fairly obvious that a GUI interface is NOT a key/base/required feature of these tool suggestions.

• I never mentioned a GUI interface either. I meant a software interface, i.e., the API or means by which it's accessed from a host language, but as no interface details of any kind were given, any information on any kind of interface is more than we had before.

Re: "no data model"

What do you mean?

Is it based on tables? Predicates? Sets? Sparse matrices? Lists?

• See "Structure" below.

Re: "no architecture"

I'm not dictating implementation at this point. Although dynamic-friendly suggestions and possible peroformance trade-offs are given in spots, such as [link to be inserted].

Re: "no sample database schema designs"

If one is not using the "on the fly" feature (above), it would be like DDL etc. as found in typical RDBMS. Although, I should point out that due to the "virtual" rule, there is no use in explicitly "creating" a non-typed ("dynamic") column unless it's designated as a "required" column.

Until you describe this, how would we know?

• I believe I've already described this in multiple places.

Re: "[not] anything that gives me the slightest indication of what it would be like to use a MultiParadigmDatabase."

I thought I did supply enough. I cannot read your mind to know where the gaps are in your mind. I will try to work on a more "linear" step-by-step example that incrementally builds up so that the info is not as scattered as it is now.

Where are the examples that demonstrate how it's used?

Re: "...what makes you think [these dynamic database suggestions] can be understood from nine brief bullet-points?"

There are roughly 5 pages of discussion and examples, not just bullet points.

All I see are nine bullet-points, one context-free code example, and lengthy debates that provide little to no edifying information. I would expect a clear description that doesn't require the reader to divine details from dubious debates.

I'm sorry you had a hard time absorbing it in that format.

---

"Structure" and Related Examples

Somewhere I mentioned it would be the equivalent of a linear textual list of XML statements where blank attributes are not stored. (Assume different databases are stored in different XML files.) Out of the box, the only required attribute is "row_id", which is automatically generated, read-only, and unique for the file. For DynamicRelational, the "entity" attribute is also required, and the row_id would be unique per entity...

Moved rest of examples to DynamicRelationalQueryExamples.