Relational database?

[Jeremy X]

On the website is written (under features..) "relationship betwenn entries".

What does this mean?

As far as i know MEMENTO is NOT a relational database. Correct?

[Bill Crews]

Memento is relational-ish, but it is not relational. It is closest to relational when using only one-to-many relationships, but even then, links are hard-coded. Memento supports many-to-many relationships by default and also supports one-to-one relationships. Keys (referred to as Entry Name) by default are not required to be unique.

What matters is why you care if it is relational. If you have SQL or want to code in it, Memento is not your tool. If you want to use relational extract/transform/load (ETL) tools, not with Memento.

However, it is a very capable database tool with features not only for complex linked "tables", but also for simple "forms", for data charting, for barcode scanning and searching, team collaboration, and many other things.

[Eugene Kartoyev]

I don't see what makes Memento not relational or just relational-ish for you.

The primary keys are unique and stored in the memory. The user is not shown the keys, but they exist. You can see the keys when you upload a record to GS as MEMENTO_ID.

It is absolutely clear, that this key is used to access records in another library. Otherwise, the hardcoded (as you presumed) user keys (Entry Name) wouldn't point at a correct record when entry names are repeated, for example.

Besides, if you change a name in one library - it will automatically change in the second library. Which is another proof that links are NOT hardcoded, but referred to via a key.

Additionally, when the entry name is intended to become a key, for example, when uploading to GS, Memento proposes this field to become unique. Otherwise, when you synchronize it back, Memento won't know where to assign repeated records.

To top it off, when you delete a record, the link remains active until you clear the bin. Another proof of that links are not hardcoded but referred to another lib's record via a key.

Finally, Memento uses SQLight - which is a relational. In fact, the database is Sqlite, not Memento. Memento is just a convenient interface.

Thus, the correct answer is yes, Memento is fully relational, both according to its behaviour and the definition of a relational database.

https://en.m.wikipedia.org/wiki/Relational_database

[Jeremy X]

Sounds good.
Have downloaded the PDF user manual an will have a look to this.
If i need a bit help in designing the database i hope i can post it here.
Thanks for your answers.
Regards Andreas

[Bill Crews]

Eugene, this is really funny to me, because until now, I've always argued YOUR point AGAINST people claiming Memento is NOT relational. For one example, see https://groups.google.com/forum/m/#!search/relational$20memento/mementodatabase/SRBCxIxVZe0.

The main points of my answer are in my original post; try rereading it. The key IS hard-coded; The fact that the Google Sheets sync interface exposes the hard-coding doesn't change that. Memento says "Don't touch that field value!", so it is exposed only because there is no other way, not so the user might do something with it.

Changing a field value in one library changes it in the other proves only that the libraries are linked, not that the link is not hard-coded. They are certainly linked.

Yes, one COULD set entry names to be unique AND set a link to be one-to-many and you are getting close to relational, but those values are not the defaults.

What tools (SQLite), libraries, & such are used inside the app is immaterial -- only what is exposed in the interface.

What stopped me from arguing how relational Memento is was (1) I already knew the keys were not unique by default, so many Memento libraries probably don't have unique keys. (2) Vasya implemented 1-1 and many-many links AND made many-many the default. Now, most Memento links will probably be many-many. I had been imagining putting a SQL layer on top of Memento, but he's clearly going in a different direction.

You and I participated in a group conversation a while back in which Bob said "There seems to be no way to import already populated fields which would then be used as the key fields, (or "link to entry" in Memento parlance), which would be used to establish the joins between tables. I have been toying with the idea of using Memento to develop a small business application for my sister's business. The application would require importing Customers, Inventory and Delivery Routes into the database. The relationships between those tables has already been established by common data in key fields (columns). This would be an impossible task if we have to go into each record and establish the "link" again individually between records."

And he's right about that. That's why I remarked in my original post about SQL and ETL tools; that isn't going to happen.

Since you sent me a URL, here's one for you: https://en.wikipedia.org/wiki/Codd%27s_12_rules?wprov=sfla1 -- Codd's 12 rules. In my opinion, Memento violates Rules 4, 5, 8, 9, and 10.

Finally, every time someone asks if [pick your tool] is or isn't relational, several long messages get posted, and I'm usually one of the posters, and it is tiresome, BUT the discussion is enlightening, for people who don't get too bored to finish reading it all. In truth, many rDBMSes are not TRULY relational, but does it matter? It is a word game; we should get down to what people really need and care about.

And don't forget, Memento is my FAVORITE database tool! I'm not trying to run it down, just make sure folks know what it can and can't do.

[Eugene Kartoyev]

Oh no! 

With all due respect to your liking this tool, I guess I will have to repeat myself. 

If Bob said then he couldn't import an interlinked database, it doesn't mean it is impossible. 

I was trying to explain, but nobody was trying to get my point, I guess. Here is a simplified recipe:

1) Prepare your library templates, establish all necessary link fields between them.

2) Now, KEY ACTION: In each library make the name record have the same name and type as the primary key in the imported library, 

3) Import the libraries in the right order.

4) Enjoy looking at your libraries interlinked via the record names, where the foreign primary key was inserted. 

At this moment, Memento will generate it's own MEMENTO_ID key and the imported primary key becomes irrelevant. Now, you can go to library settings and change the record name to some other convenient record, and delete the foreign primary key - as you may no longer need it. All the links will be established via MEMENTO_ID key

I had a different understanding of Hardcoded. If you mean automatically generated -- it is absolutely true and it must be. This is done in all respectable databases, because nobody wants a user to mess up with the unique primary key, by which she can ruin all the links. 

Besides, the primary unique key could be a string field, or a bytecode or something else, depending on the database interface. 

Therefore, it is for the interface to decide what the primary key should be.

Not keys, but fields are not unique by default. But the primary key is unique. Just allow your Memento generate that primary key on its own, and use the name entry for importing somebody else's primary key, which could be anything. 

This technique is only logical because you don't know what type of key is used as primary key in another database, it could be 8976876, or it could be JHLKHL, or a 2016-10-15-10:30:55 

The solution which Memento provides, not only allows it to import any database from any source with any primary key, but also makes it idiot-proof by not exposing the primary key - in case someone else may want to mess up with it.

Rules from the wiki are about database. Memento uses the standard SQLite inside -- and it is very material. Vasya's good decision was that he didn't invent some database wheel, but used the internal Android's sqlite, which is well tested and universal, allowing instant search, sorting and keeping infinite number of records. I was wondering if my database was not full of programmer's intermediate data, duplications and garbage. As soon as I knew it was Sqlite - I became assured of that Memento could be trusted for speed and effiency.

In theory, you could use some web or even DOS interface to interact with the SQL if Vasya hasn't set up some specific password to the Sql content. I don't know, I didn't investigate into that yet.

The many-to-many concept actually doesn't exist in a relational database. In fact, many to many field is just one-to-many concept, where one field has several records with primary keys of other fields separated by a comma. Which is a pleasant add-on in Memento, making it even more relational than it should be.

[Bill Crews]

Eugene, you are largely correct, very bright, and very helpful in this group to other users. Relational theory, as it evolved on mainframes and large minicomputers back in my day, is germane to any database implementation. However, there are SO many other factors, and the user base have SUCH different concerns and budgets, that I'm not sure it makes a lot of sense to pound out a common understanding.

But for one thing, by definition, a primary key is part of the logical data model, not a generated key used for physical storage.

I'm sorry to stick with relational-ish, but I do. You have agreed that the typical, default Memento library -- with nonunique entry names and many-to-many links -- is not relational.

Let's let this go. If you are interested, perhaps you could read https://www.amazon.com/Relational-Theory-Computer-Professionals-Practice-ebook/dp/B00CXXZ6PQ/ref=sr_1_1_twi_kin_2?ie=UTF8&qid=1476501053&sr=8-1&keywords=Relational+theory+for+computer+professionals

[Bill Crews]

Sorry, Eugene. It was an ebook reference. You could just download a sample or look for it elsewhere. The author, Chris Date, and his associate, Edgar Codd, invented the term and the theory of rational databases. There is no more authoritative source. You and I could take issue with them, but that won't be of much use to anyone.

I think we (everyone) should get over worrying about whether something is "relational" or not and discuss what actual issue is at hand. Whenever people ask, I try to answer very generally and then ask them what their immediate concern is. Then I can address that instead of descending into these depths of whether one of us or the inventors themselves are right or wrong about everything. I'm only trying to be helpful to people. I don't care who's right or wrong. I mainly want to just quit talking about it unless someone needs some real help with a real problem. Then, I'm all ears.

By the way, without knowing what passage you're referring to, my guess is, knowing Chris Date as a purist, that he probably feels that current standards (or maybe current implementations) of SQL violate Codd's relational rules, or allow RDBMSes to do so. It's probably some esoteric consideration, and within that narrow context, he's probably right. But as always, I may be wrong. I'd have to read the context.

Peace, brother.

[Eugene Kartoyev]

You are absolutely right, Bill. It's the purist idea that SQL is just relational-ish because it allows non-relational implementations. Now, I get the point of what you mean by relational-ISH. That is allowing non-relational implementations. So, it all depends on the user, - on how they treat the entry name if and when they intend to use the entry name as a primary key.

In any case, you are also right that those are esoteric questions and are of little importances as long as Memento does its job correctly.
Thanks for clarifying your point.