''Material moved from TupleSpace.''

I'm thinking it wouldn't be such a hideous AbstractionInversion to use an RDBMS to implement a TupleSpace.

Instead of having different kinds of tuples, you simply have records in different tables.  Since most modern RDBMSs provide in-memory tables, you have the possibility creating/consuming large numbers of them without hitting the disk space (so long as you can keep your tables small enough to fit into memory).  The transactional nature of such things would seem to be a good fit for Linda's atomic operations.  Additionally, if something happened which caused a transaction to fail, the ability to roll-back to a known state and try again would be very helpful.  In this respect, I see quite a bit of the development surrounding Linda as re-inventing the RDBMS wheel.  Naturally, you'd want to do it in a more lightweight fashion, so much as possible.  Eliminating the SQL engine and providing an API to access data/perform operations would be a good start.

Many of the Linda tasks you create are based on "consume a tuple of this type, do X calculations with it, emit a tuple of this other type, repeat as necessary."  This would require something repeatedly polling the database, looking for an input tuple to consume.  If you could use triggers, which spawn or execute that process every time a record is written to the appropriate table, you get an interrupt-driven process instead of a polling-driven process; from there, it becomes a question of the DB server's ability to manage large numbers of spanwed tasks.  Add in the fact that, for many, modern RDBMSs you can have a cluster of machines, sharding the data from a specific set of tables across multiple physical machines, and you have the ability to scale across multiple physical machines for increased performance.  Indeed, while you may want some of the records persisted for actual consumption outside of the process, if the vast majority of "intermediate" results, working toward those records, can be done entirely in memory, it may be worth your while to have several physical machines which only shard the in-memory tables and handle the bulk of the triggered processes.

While such a system would be a bit of overkill, I suspect there are more people who are well-versed in the care and feeding of RDBMSs than there are developing with Linda.  This could be a good "jumping off point" for introducing more people, inside and outside of various enterprises, to the concepts in Linda.

Are there papers out there about people already trying this? Or have tried this? I have to think I'm not the only person thinking in this direction, but I'm coming up short on hits on Google.  It's possible I'm just not searching on the right terms, yet. -- Meower68

''It's not clear to me what RAM has to do with it. That's more or less of an implementation detail, not a database "user" interface issue. Often it's best to focus on the UI/language/interface aspects of a "technology" first, and ''then'' consider implementation issues. Of course it's not always seamless because machine/performance-issue trade-offs often dictate what's available or feasible.''

To clarify, one of the performance advantages which a TupleSpace frequently has over an RDBMS is that the TupleSpace lives only in RAM.  I'm merely suggesting that a modern RDBMS, with memory-backed tables, would bring the performance closer to parity.

[Any DBMS or TupleSpace developed in the last few decades makes extensive use of caching, to the point that disk speed generally isn't an issue except (possibly) at startup whilst the cache is being populated, or if the pattern of retrievals results in a significant quantity of cache misses.  The most notable conceptual distinction between a TupleSpace and an RDBMS is that in an RDBMS, tuple storage must be organised into a finite quantity of predefined tables.  TupleSpace''''''s do not have this structural constraint.  Depending on the application, this may be a help or a hindrance.  If there are a wide variety of tuple types, the overhead of creating one table per tuple type (or of using some schema that supports arbitrary tuple types, such as EAV) may prohibit using an RDBMS.]

How is this different from MultiParadigmDatabase (other than dynamic typing issues)?

[For one thing, it exists.]

Lovely, the wonderful LearningWithoutImplementation fight yet again.

[If MultiParadigmDatabase were a clear and rigorous model instead of a bag of vague ideas, LearningWithoutImplementation would be possible using it.  As it stands, who knows what is or isn't part of a MultiParadigmDatabase?]

Try it on something. If there's a vague spot, let me know and I'll fix it; plug it with details. Sure, life is easier with an implementation, I won't dispute that, but that's not a show stopper to exploration.

[Without a clear definition of "it", that's rather difficult.  It's much easier to reason using a defined language syntax or mathematical notation.  Is there an example of a MultiParadigmDatabase with either one?] 

What's not clear? Point out specific fuzz and I'll happily shave it. As a guideline for MPD, if it's not specified, then assume traditional-RDBMS conventions. I wouldn't deviate from familiar RDBMS conventions unless it interferes with the primary goals of MPD, such as dynamism.

[What's not clear is what language syntax or notation is used to work with a MultiParadigmDatabase.  If the answer is to "assume traditional-RDBMS conventions", then why shouldn't I assume a conventional RDBMS and ignore MultiParadigmDatabase?  What, specifically, is different about a MultiParadigmDatabase in terms of the syntax and/or semantics of the database language used to manipulate it?]

Let's see:

* One would use "entity" references in the WHERE clause instead of table names.

* Comparison operators would need to be clear about what type they are comparing on (ComparingDynamicVariables).

* Ambiguously-typed operators would need to be cleaned up. For example, string concatenation would best to be clearly different from numeric addition. (I never liked that overloading anyhow.)

* New tables (entities) and new columns can be added by an INSERT statement. There are no ADD TABLE or ADD COLUMN commands.

* Unless nulls are switched on in the configuration, you shouldn't rely on explicit detection of them.

{Why don't you describe the syntax you'll be using directly instead of just trying to list the differences? I'm sure you've missed some (differences) since I don't see how you'll be able to do a join at the moment.}

Why should we hard-wire the engine to a particular language? That's old-school. Granted, it can be used to explore certain aspects of an engine, but also risks locking in thinking.

* {All the points you make above (except for the last, maybe) are about the language. In fact, all the differences above can be implemented on a regular database using a different language than SQL. It would make certain tasks involving security and data integrity difficult, but it could be done.}

* No, it's not about language. If the "engine" doesn't store nulls or explicit type tags, yes it will indeed likely affect shape of the language (or at least how it's used), but that's not the same as dictating the language itself.  

* Re: "all the differences above can be implemented on a regular database using a different language than SQL." -- Yes, because existing RDBMS can implement a map of maps, perhaps using an AttributeTable. However, it's round-about to get row-centric queries that way. Ideally, we want "natural" rowness. We want rows to "feel" like the do in SQL.

* {And the other points? Can you show how they aren't part of the language? (Not that your argument that the final point isn't part of the language is very convincing.) And you don't need a map of maps to implement any of the points you made above.}

** You do need it if you want to have those AND keep much of the existing RDBMS features and "feel". Otherwise, present something that fits but is not close to a map of maps.

** {No you don't. Your first point can be implemented by reserving a particular column name and treating it as the table name. Your second can be implemented by spelling the comparison operators differently. Your third is really just a repeat of the second (but for other operators) and has the same solution. Your fourth can be implemented by creating a table when a value for the reserved column is being entered into the database, but doesn't already exist. (We can also delete tables when we remove the last instance of that value from that reserved column.) Columns are treated similarly. See? No need for a map of maps at all.}

** {For example, say you issue a "SELECT foo, bar, baz WHERE table='buz' and foo='biz'". Now, say that foo and bar were names that already existed, but baz was not. That statement would translate to "SELECT foo, bar, baz = null FROM buz WHERE foo='biz'"}

*** You wouldn't necessarily know whether baz exists up front. More on this below.

** {Now say you issue a "INSERT (table, foo, bar, baz) VALUES ('buz', 7, '15', 42) where buz does not exist. This would translate into "CREATE TABLE buz (foo, bar, baz); INSERT INTO TABLE buz (foo, bar, baz) VALUES (7, '15', 42)"}


** {finally, say you issue an INSERT (table, bar, baz, biz) VALUES ('buz', 7, '15', 42) where buz, bar, and baz exist, but biz does not. This would translate into "ALTER TABLE buz ADD biz varchar(4096); INSERT INTO TABLE buz (bar, baz, biz) VALUES (7, '15', 42)"} 

** {Note: that the varchar(4096) can be replaced with whatever length you feel is necessary.}

** How do you know "baz" doesn't exist up front? I'm '''not making the assumption that we know existence up front'''. In fact, one can put random names in the SELECT clause and receive no error messages whatsoever (as long as they follow the column/attribute naming rules). The result is just empty columns. This is the "limp" philosophy in LimpVersusDie. Also, it may not necessarily be easy to determine if an attribute happens to be used on some obscure row without sequentially scanning the entire database. We could index on such in the engine perhaps, but I'm not making that a requirement of MPD such that you shouldn't rely on it to make an emulator with traditional RDBMS. Thus, determining "existence" of a column should be assumed to be an expensive computation unless explicitly indexed. This is part of the reason I prefer calling them "attributes" instead of "columns". I'm not disputing one can make an emulator using existing RDBMS, but it won't be trivial. It seems to me that using an AttributeTable would probably be an easier emulation route than trying to mirror the rows in a traditional RDBMS. -t

** Also note that the table references are optional. Mapping no table references using gazillion UNION statements in your emulator would be a bear.

** {There's no need to know if "baz" exists up front. The semantics are dependent on whether or not it exists, but we can make that determination when we translate from your MPDB language to SQL. And yes, if a table doesn't exist, it would return an empty result set, so that's not a problem either. Checking to see if there are any non-nulls in a column does not require scanning the entire database. All it takes is scanning a table. And even then, we can limit it to non-null columns where we've deleted a row or updated to a null. If a full table scan gets to be too expensive, indexes can be used to make the check extremely efficient. In any case, I'm not talking about an emulator, so I don't know why you brought it up.}

** But then you are mixing "regular" query statements with schema-change query statements to emulate it. I believe the first is called DML and the second DDL in SQL-speak (data modeling language and data definition language). Granted, it can be done, but is awkward. More on emulation effort below. And, you didn't show the step of checking column existence, making it appear that it's probably the human query writer's job to do such.

** {I'm not emulating anything. Neither does it matter that I'm mixing DML and DDL. In fact, it's not surprising that I'm mixing the two, since that's what your requirements do. How one checks for column existence is dependent on the RDBMS. In addition, the exact details aren't important to my point. So, I left those details out. Once you've picked an RDBMS, it almost always simple to automate the check for column existance.}

** MPD doesn't mix DML and DDL, but rather blurs the difference, making it mostly irrelevant. The rest of your statement raises an interesting question:  '''how are DBMS's defined''' if wrappers can be added to make one emulate/resemble the other? Is it defined by (native) query language? By performance characteristics? It's not by features if they each can be cajoled into cross emulation (or whatever you call it). I don't believe at this point there is an easy answer. Language, characteristics, and features tend to support each other to create a "flavor". You can force them to deviate from their preferred flavor, but it requires more complex wrappers and/or creates unexpected or "foreign" performance characteristics. For example, a MPD-flavored DBSMS will be quick to "add" columns compared to a TRDBMS, but it would be slow to determine all "defined" columns in a given table (or equiv). One could probably also emulate a RDBMS on IMS and vice verse, but the performance characteristics will probably create surprises.

** {Whether you call it "blurring" or "mixing", the fact remains that things currently done via DML and things currently done via DDL are combined into a single statement. In order to translate that into SQL, you will have to use both DML and DDL. It's not a problem, and I don't understand why you think it is. As for the rest, the requirements you gave are all requirements of the language used to access the database, not requirements on the workings of the database itself. I suspect that if (and that's a big if) a language with your requirements ever catches on, you will find that the internal workings of the RDBMS will be modified to allow for faster DDL (probably at the expense of the DML portions).}

** There are other performance characters to consider, such as removal of "unused" columns (column GarbageCollection, more or less). But anyhow, it's too early to know if tweaking an existing RDBMS engine would be competitive with a MPD-flavored engine designed from scratch for a MPD-flavored language (dynamism of columns and tables). It may depend on how it's being used. I suspect the later would have noticeably better characteristics if a lot of dynamism is being used by the domain (or project stage), but favor the first if not due to its roots as a static engine. 

** Another curiosity to consider: in a sample MPD we change the "table=" attribute from "foo" to "bar". Using a TRDBMS, the "translator" (for lack of a better term) would need to add any new columns to the "bar" table after checking the existing schema, remove any unused ones from table "foo", copy over the row fields, and remove the "old" row. That's much more involved than changing one attribute (and probably an index entry under the hood) in the guts of the MPD-flavored engine.


* Any TuringComplete language can work with it; it's a matter of convenience.

* {How is that relevant?}

* Perhaps I misinterpreted your question. A language can be shaped by such features to make it easier to interact with the tool/engine, but it doesn't have to be. For example, you can use a static-typed language for it, but you'd probably end up doing a lot of conversions.

* {That appears to be even less relevant. You are being asked about the list of differences you gave between traditional RDBMS and your MultiParadigmDatabase. When you balked at describing the language used to access it, you explicitly denied that those points were about language. I'm asking you to defend that denial.}

* Emulation is a matter of degree of effort and code-size. The closer the language natively "fits" the underlying engine, the less complicated the emulator will be and the more predictable the performance characteristics (such as dynamic columns coming and going without lots of delay).

* {That's even less relevant. Nothing else being said here has anything at all to do with emulation.}

* If everything can emulate everything then everything is everything. One can similarly emulate dynamic-ness in static languages, but it's usually more awkward then just using a dynamic language to begin with. Further, the performance profile may be far different than what one expects, such as adding "new" columns (attributes) in rapid succession. In MPD, such would have the same performance profile as adding any other row (as one would expect), but with TSQL emulation, it could be very slow because it's a schema change in those things.


Forget indexing, performance, and multi-processing issues for the moment and think about what's the best way to interface with and use a map of maps where the primary key is an auto-generated number and there are no explicit "type tags" on attribute values. Let's say the test implementation is just one big CSV file. Is that helpful?

* Actually, CSV would be a bit awkward. Non-nested XML may be more fitting so it's easier to spot attribute names.

''No.  A specific language can be particularly illustrative, especially for comparison purposes, but if you want to avoid any specific language you'll need to clearly specify the operations that can be performed on a MultiParadigmDatabase.  See how this TupleSpace page starts by identifying the operations on a TupleSpace?  At the very least, you need to provide some equivalent before a MultiParadigmDatabase can be compared to a TupleSpace.''

Most of those are relatively generic get-and-put kind of things. The real meat is in the queries. But we can use SQL-style or SmeQl-style as starting point. If some unanticipated conflict arises between traditional RDBMS and the dynamic nature of MPD, we'll deal with it then.

If you are used to relying on null-ness for your query language or coding style, you may have to rethink your approach. There's likely a way to do the same thing, but it will feel different.

''That's a bit vague and open to interpretation.  Please document the operations on the MultiParadigmDatabase, or at least clearly describe, in detail, how the operations of a MultiParadigmDatabase differ from SQL and/or the RelationalModel and its RelationalAlgebra.''

You can say, "I personally won't experiment with the idea until I have an implementation to play with". That's fine; that's your prerogative. You don't have to. (While we are on IwantaPony, I'd like to see some sample queries with TupleSpace like "Find all employees who make more than their boss", by the way.) But that doesn't mean there's '''no use''' in considering the idea on paper. We have static languages and dynamic languages, and it similarly makes sense to have/consider static DB's and dynamic DB's. One can kick around dynamic DB ideas on paper. 

''No, I personally won't experiment with the idea until I have a specification to examine.  The notion of MultiParadigmDatabase appears very nebulous, and therefore potentially subject to debate over what is, or is not, part of MultiParadigmDatabase.  When it's clearly and comprehensively specified, then I will consider it.''

A key question is how close such a contraption can stay to existing RDBMS conventions and still be dynamic. What must we keep and what must we toss? To "market" the idea, we should probably stick close to RDBMS's if possible. TupleSpace appears to have made very little effort to at least stay in the same neighborhood as RDBMS. 

A related question is whether to have type-tags associated with attribute values. Of course I'd want to skip them, but the idea of "explicit" dynamic typing should be considered to see what the design choices would be. For example, would the tag be associated via a column name (all rows), a specific "cell", or an inheritance-like combination? 

''You're obviously still considering what should, or should not, be in a MultiParadigmDatabase.  As long as the notion so is amorphous, it's difficult to consider it an alternative to something as well-defined as the various TupleSpace implementations, or even the TupleSpace concept in general.''

If that's true, then show me the TupleSpace query of "Find all employees who make more than their boss".

''Typically, high-level queries with joins and the like are outside of the scope of TupleSpace implementations which retrieve tuples based on keys or matching values.  High-level queries are implemented by performing further operations on the retrieved tuples.  That's why a TupleSpace is suggested as a foundation for (say) implementing tables in a relational database, rather than the other way around.''

So as-is, TupleSpace is either not "finished", or not competitive with traditional RDBMS. It's closer to a persistence-oriented machine language.

* ''It's as "not 'finished'" and as "not competitive with traditional RDBMS" as a telephone is to a truck.  A TupleSpace is more of an asynchronous communications and parallel processing facility than a DBMS.''

* A DBMS is typically also "an asynchronous communications and parallel processing facility" to a large extent, or at least provides services to facilitate such, including transactions, ACID, and parallel query processing.

* ''A DBMS does do asynchronous communications and parallel processing, but it's not designed specifically '''for''' doing those things.  A DBMS is designed primarily for data storage and retrieval.  Likewise, a TupleSpace does do data storage and retrieval, but it's designed primarily to provide asynchronous communications and parallel processing.'' 

* Well, okay, but that brings up the question of whether such features should be bundled or separated. What are example scenarios/domains where one needs lots of asynchronous communications and parallel processing but ''not'' a lot of database-like features (non-trivial-querying, cross-referencing, sorting, summing, etc.)? And why wouldn't a traditional DBMS be sufficient for those situations?

* ''Imagine, for example, an agent-based architecture for doing sentiment analysis on a variety of sources.  Whilst a database could be used to keep track of the list of sources -- representing URLs for various Internet forums, news sites, Twitter, Facebook, G+, etc., and identifying their access mechanisms -- the primary focus will be running natural language processing in parallel on content downloaded from highly-dynamic Web-based sources to generate an overall rating of sentiment -- e.g., favourable vs unfavourable; angry vs happy, etc. -- and/or to look for items demonstrating a particular sentiment given an ad-hoc topic like "Mosanto" or "Miley Cyrus" or "Syria military action".  This is a process that requires a lot of asynchronous communication, parallel processing (plus HTTP transactions and natural language processing) but requires little to no non-trivial-querying, cross-referencing, sorting, summing, etc. on a database.  Notably, storage in the usual DBMS/database sense is not required, other than the list of sources and an indication as to whether a source has been processed or not.''

* I don't have enough experience with AI/natural-language-processing to comment on that particular domain. -t

* ''You might need to do some Googling for terminology you don't recognise.  Nothing above is "AI" per se, and sentiment analysis is an established and well-documented field.  Note that you did ask for "example scenarios/domains where one needs lots of asynchronous communications and parallel processing but ''not'' a lot of database-like features".  I'm a bit concerned here that if the only experience you have is with scenarios/domains that need "a lot of database-like features", you're not going to appreciate '''any''' example that doesn't need "a lot of database-like features".''

* Brain surgery is also "well-documented", but I don't want to delve into it at this time. (I almost purchased "Self-Lobotomies for Dummies").

* ''I presume you aren't a neurosurgeon, so I wouldn't expect you to understand brain surgery.  I presume you are a programmer, so I would expect you to understand -- or be able to easily gain a superficial but sufficient understanding of -- sentiment analysis.  Again, we're going nowhere with this if the only scenarios/domains you understand are those that need "a lot of database-like features" but you ask me for examples that don't need "a lot of database-like features".''

* I don't know if it's the case that "the only scenarios/domains you understand are those that need 'a lot of database-like features' ". One scenario is too small a sample size to test your statement with.

* ''Sure, but you know yourself better than I do.  Only you'll know whether I can clarify things with one more example, or whether we'll be no closer to you accepting that there are valid uses for a TupleSpace that don't need "a lot of database-like features" after I've given you twenty examples.  That said, here's another example:  Imagine a music generator based on individual but collaborating "virtual musicians" that share information but also act autonomously.  There is no need for database-like features, but a lot of need for asynchronous communication and parallel processing. (I like this one so much I'm going to propose it as a student research project this year -- it'll be interesting to see how it turns out.)''

** ''[Some time later...]  So I did propose it as a student research project, and one of my undergrads is working on it now.  He's making good progress, and has expressed interest in continuing it as PhD research.''

* If they are '''virtual musicians''', you don't even need parallel processing, just decent round-robin-ing with the processing time, because they don't have to run in "real time" (human speed). (Incidentally, I dabble with automated music composing at times, but don't claim to be an expert, just a "weekend dabbler". I'll send somebody an experimental tune if they are interested. It's kind of new-age Bach-like.) -t

* ''How about we add in a human conductor/bandmaster so that it does have to run in real time?  You're right, you don't need parallel processing, but you don't need high-level languages, either.  You don't even need low-level languages, just code the thing in raw assembly language by stuffing RAM with binary.  We use high level abstractions because they make the problem easier to express.  That makes the job easier.  A high level language makes programming easier.  A TupleSpace makes collaborative parallel processing easier.  A DBMS makes data storage/retrieval/fact-management easier.  You can, if you like, even use all three together.  Choose the right tool -- or tools -- for the job.''

* And even if it was real-time, what would keep an existing TRDBMS or a custom-tuned TRDBMS from handling it?

* ''Probably nothing, but is it the best way to express the problem?  Given that a virtual "jam session" for music generation involves a lot of asynchronous communication and parallel processing but none of the usual "database-like features", I'd argue that a TRDBMS isn't the best tool for the job.''

* Every app probably has a theoretical "ideal" data collaboration tool that best fits it. The practical question is whether it makes sense to find, create, and/or support a custom or small-niche data sharing tool for each app. I don't dispute there may be a niche for TupleSpace-fitting apps, but it's difficult to know the extent of such a need. Plus, if needs grow or change, then locking yourself into a narrow tool may backfire. Something that is "good enough" in many categories may be better in the longer run than something that does only a few things really well.

* ''I'm quite confident that rational developers can be trusted to decide whether to use a TupleSpace, a DBMS, or both, to meet a given set of short and long-term requirements.''

* Many are not rational. HumansSuck.

* ''What do you propose to do about it?  Outlaw DBMSs to prevent an irrational developer from using one when he should have used a TupleSpace?''

* God, I wish I could do that with overloaded dynamic languages.


{It's finished, it's not a direct competitor to an RDBMS (you could implement an RDBMS using one, or vice versa), it may or may not be persistent, and it's most certainly not a machine language.}

It's a lower-level language than "typical" query languages; above machine language but below a "high-level" languages like say SQL or Python. But if it's not intended as a competitor to traditional RDBMS, why are we comparing it to MultiParadigmDatabase?

''Someone wrote, "I'm thinking it wouldn't be such a hideous AbstractionInversion to use an RDBMS to implement a TupleSpace."  Later, you wrote, "How is this different from MultiParadigmDatabase (other than dynamic typing issues)?"  In response, I quipped that at least a TupleSpace exists and we drifted OffTopic.  However, a TupleSpace could be used as a building-block in a DBMS and vice versa.  The one is not lower-level than another; they're different things.''

Comparing an unimplemented Foo to an implemented Bar is kind of odd.

''Yes, so I'm not sure why MultiParadigmDatabase was ever suggested as an option.''

You have N''''''onImplementationAphobia.

''No, I have I''''''ncompleteDescriptionAphobia.''

You are asked to design a DBMS that follows these goals in this order:

* 1. Dynamic tables and columns
* 2. Can be used reasonably well for multiple paradigms
* 3. Fits the conventions of existing RDBMS
* 4. Simplicity via idiom reuse, etc.
* 5. Machine performance

Go!

''Those are a reasonable set of requirements, but not much help in terms of a technical description.  At least please document the operations on the MultiParadigmDatabase, or clearly describe, in detail, how the operations of a MultiParadigmDatabase differ from SQL and/or the RelationalModel and its RelationalAlgebra.''

I too am curious about what general design you'd select given the above criteria. A rough description is fine with me as long as you explain/refine specific spots as requested.

''Isn't that OffTopic for this page, not to mention avoiding my (reasonable, I think) request?''

Most of this sub-thread is off-topic. It's a bit late in the game to complain. [Since moved out of TupleSpace.] And, I believe my request to be "reasonable". Asking somebody to make an ''entire'' running system ''just'' to comment on it is NOT realistic.

''Your request is quite unreasonable if you're not intending to define it in any more detail than a list of vague requirements and then expect us to design it for you.''

I expect a discussion of the kind of trade-offs and features such goals would entail. We have "static" DBMS already, and so asking to kick around designs and explore the implications of dynamic DBMS designs is not unreasonable. Every project should have a brainstorming step. 

''So, you regard MultiParadigmDatabase to be sufficiently defined that you can ask, "How is [a TupleSpace] different from MultiParadigmDatabase (other than dynamic typing issues)?" and expect (presumably) a reasonable answer, but it's not sufficiently defined for you to identify how the operations of a MultiParadigmDatabase differ from SQL and/or the RelationalModel and its RelationalAlgebra and suggest that we now "should have a brainstorming step"?''

I thought it was mutually agreed they cover different concerns. For example, TupleSpace doesn't include a query language beyond simple accessors. The difference between MPD and TRDBMS (traditional) is probably very much smaller than the diff between TRDBMS and TupleSpace.

''What does that have to do with what I wrote?''

I'm not sure what you are getting at. Note that it's still possible to brainstorm about dynamic DB's independent of MPD. You seem to be suggesting they are mutually exclusive. Feel free to split such off to a different topic if you wish to avoid mix-ups.

''I didn't mention "dynamic DB's".  It appears you consider MultiParadigmDatabase to be well-defined on one hand -- such that it's reasonable to compare it to a TupleSpace -- but insufficiently defined such that you feel the need for a "brainstorming step".  That sounds contradictory.''

I don't have a need for it. It sounded like you did, so I suggested it as a potential course of action. I am curious how you'd personally solve the goals/constraints given in order to contrast the result with MPD, but if you don't want to consider such, that's fine with me. 

''Sorry, not clear here:  What "course of action" were you suggesting?''

Brainstorming.

''To compare a MultiParadigmDatabase with a TupleSpace?''

No. To compare one dynamic DB design suggestion to another dynamic DB design suggestion. TupleSpace does not qualify as a DB in my book because of its very weak query capabilities. I am interested in dynamic versions of RDBMS-like tools and welcome design suggestions. If you are not interested, then I invite you to enjoy your exiting of this topic.

''No one claimed a TupleSpace is a "DB", a database, or a DBMS and it appears you agree that it isn't.  Therefore, I'm curious why you thought it similar enough to a DBMS to ask, "How is [a TupleSpace] different from MultiParadigmDatabase (other than dynamic typing issues)?  Furthermore, I'm curious what you thought was so similar about a TupleSpace and a MultiParadigmDatabase, given that a MultiParadigmDatabase apparently still needs brainstorming to determine what it is.''

I'm not the one who brought up TupleSpace''''''s in relation to RDBMS and related DBs.

''True, but you continued the discussion in a particular direction.''

I was just probing to see if there was a useful connection.

------

For typical usage, querying the MultiParadigmDatabase wouldn't be that much different than using "traditional" SQL. If the query interpreter translates table names into "entity=" or "table=" WHERE-clause references under the hood, then even the table-ness feel would still be there. The comparing operators may have to be de-overloaded to make the compare type more explicit, and how the equivalent of null-ness is handled would often be different, but these only affect a small portion of most queries. The '''real difference in "feel" is on the schema-design side of things''', not the query side, as schema "design" (or non-design) would be far more ad-hoc, at least out of the box (as restrictions can be custom added). -t

And I wouldn't use Perl's comparison approach for reasons described in ComparingDynamicVariables.