Re: How to efficiently make an "history" ?

> "Wandering Explanation, Pointless Metaphor"

No comment... Basic respect would be appreciated.

> :> Secondly, SQL has no "fields" -- tables are made of
> :> rows, rows are made of columns and columns hold values. This is
> :> important!!
>
> : I didn't know rows were made of columns. I thought that tables were made
of
> : rows *and* columns.
>
> A is in B, B is in C, thus C is comprised of B and A.
> columns are in rows, rows are in tables, tables are comprised of rows and
> columns.

This is what I said: I didn't know columns were in rows (but I knew tables were comprised of columns and rows).
(and I am still unsure about this.)

FYI, I don't really understand people wanting to be accurate to say "column", "row", etc. instead of "field", "record"... Wouldn't be more accurate to say "tuple", "attribute", "relation", ...

OK, I go back to the interesting part of the e-mail.

> Correct, of course, but that doesn't affect columns being a part of rows.
...
> : I *need* to keep old values, all, and why they have been changed. This
is a
> : business requirement.
>
> Like he said, keep a log file.
>
> : The exactly same case exists in the retail business: you want to keep
the
> : historic (maybe not the good term...again) of all prices a particular
item
> : had at a particular moment. You want to be able to query this, make
> : calculation, ...
>
> : And what is the advantage of a text file over a SQL database in this
case?
>
> You don't have terabytes of old rows sitting around in OLTP tables.

So, it is more a performance concern than a design concern, right?

> I recommend investigating your RDBMS's support for partitioning. If it is
> not too clunky, partition all your tables into 'current' and 'historical'
> areas. Then you can keep all the historical rows around, but queries on
> current data will remain fast.

OK, I will take a look at this, it is a really interesting idea. Thank you.

Cheers,

                            Sacha