Re: The relational model is a wrong theory

Dana ponedjeljak, 28. listopada 2019. u 19:19:51 UTC+1, korisnik James K. Lowden napisao je:
> On Tue, 15 Oct 2019 00:59:57 -0700 (PDT)
> vldm10 <vldm10_at_yahoo.com> wrote:
>
> > Codd's database solution only stores the last attribute-level value.
>
> Yes.
>
> > This is the simplest case of a database solution.
>
> Many would say still simpler solutions pre-exist even Codd, but OK.
>
> > In that sense, I mean Codd's RM is the wrong solution. Codd's
> > database solution has the following data operations: delete data and
> > update data. This means that Codd's databases do not have past. And
> > that is very bad for business. In the same sense, the ER is wrong.
>
> (I think you mean "RM is wrong"?)
>
> In your opinion, then, it's a mistake for the DBMS to ignore history,
> because businesses need to retain history in their databases.
>
> OK. That's a point of view. I will say that only here among database
> theory geeks can we have a robust discussion about how SQL DBMSs are
> "bad for business" when the trend over the last decades has been for
> businesses to demand less, not more, of the DBMS industry, to say
> nothing of theoretical fidelity. I'm looking at you, NULL.
>
> My question to you, Vladimir, is this: How is expressing time in the
> database theory -- and, presumably, language -- better than dealing
> with time overtly, as data?
>
> In my world, if I have a table of people,
>
> create table people (name text not NULL primary key);
>
> I can create people without a past (rather a neat trick). If they need
> a past,
>
> create table people (
> asof date not NULL,
> name text not NULL,
> primary key (asof, name)
> );
>
> serves the purpose. A view of "current people" is easily created,
>
> select * from people as P
> where not exists (
> select 1 from people
> where asof > P.asof and name = P.name
> );
>
> You seem to want to make the history of people intrinsic in the
> language. Obviously, that makes the language more complex, because it
> has to express a new dimension, namely time. For that language to be
> "better" in any sense, it has to enable simpler, shorter queries than
> otherwise possible with simple old SQL. Can you provide an example?
>
> --jkl

I'm just moving from one city to another. When I get the internet in another location, then we can discuss this solution. In short, I work at the atomic level, that is, I work on one data. Each piece of information (a real object or an abstract object) is determined by three things (for now). These three things are who entered this information, at what time and at what location. These three data are about a real or abstract object. Abstract objects are those from computer memory. Every procedure that enters the data or the person who enters the data has its "password", so I know who entered that data in the DB. Accordingly, the time in my solution is just a tag to identify when an event has occurred. I only have two data events: 1. The event when the new information was created 2. The event when the existing data in the DB ceased to exist.

My goal was to realize the previous ideas on one piece of information (that is, on each individual attribute from the entity). That is on atomic data. Simply put, that's how I understand time. Vladimir Odrljin Received on Wed Oct 30 2019 - 00:36:02 CET