sighs
I know that replicants aren’t the same as aliases. They’re most similar to UNIX hard links which, I should mention, can be renamed. In fact, the default behavior of the CLI utility is to make hard links, not symbolic links. In other words, this concept is not new and in fact is fundamental to the operation of any modern file system or database, although the ability to add new instances of hard links is not necessarily implemented.
So I don’t really care about your thoughts and feelings regarding the philosophical and practical differences between hard links and aliases or symbolic links because they have nothing – nothing – to do with the ability to rename hard links. The ability to rename a hard link is a minor technical issue and should not (in any sane database) be answered with anything other than “Yeah, of course that’s possible, we just haven’t done the GUI coding yet to expose it to the user.” Bill, I could code an application that allows renameable instances of hard links. I could do it in QBASIC, a Bash script, an AppleScript, XCode, with sheets of paper, with an abacus. This is the most basic problem of database design and it was first solved decades ago.
But since I’m here and feeling good and patronized, let’s take a whirlwind tour of your argument that this is impossible or impractical.
“The existence of a replicant logically implies the existence of another ‘matching’ replicant – a single replicant cannot exist.” This is the entirety of your argument, and this is where I began to think that you were simply throwing words at me out of sheer force of habit, Bill, because it doesn’t make any sense. If there is no original and no copy, the two records are identical, and if that is the case then the content must be stored in a separate table from the metadata because to do otherwise would necessitate either pointers or duplication, both of which are logically and empirically excluded.
The only way that the above would not hold true would be if the record metadata is stored separately from the record content – except, for some perplexing reason, perhaps blackmail or ransom for a kidnapped child, the developers decided to store the record name in the same table as the record content. There would be no benefit that I can think of and, in trade, versatility would be lost – for instance, the ability to rename instances of a hard link.
In other words, and using a vocabulary that is more tangible than the DEVONtechnologies-approved lingo: Single hard links do exist; in fact, every item in a database exists in the form of a hard link to data stored or described in a separate table. To suggest otherwise is to describe a database layout whose poor design contradicts principles of elegance, versatility, common sense, and the functionality we observe every day.