[Interest] version control on MySQL-Qt

[Till Oliver Knoll]

Am 07.06.2012 um 19:26 schrieb Konrad Rosenbaum <konrad at silmor.de>:

> Hi,
> 
> On Thursday 07 June 2012 15:01:11 Sujan Dasmahapatra wrote:
>> I  have a mysql database which I am accessing using my tool developed in
>> QT. Tables are created. Can we create the same table with the same name
>> but with different revision.

This statement also made me think at first that he was after some "version control system" or "historised table scheme".

>> Is this facility available in MySQL  and
>> Qt........I want to update the table with the same name but new dataset
>> will be there only the values will be updated.

However this...

>> Can we do that ? Please
>> help.
> 
> No, this is not available in MySQL or any other standard SQL database. It 
> might be possible to do something like this using inheritance in Postgres, but 
> the DB may be pushed towards its limits with this.

... and Sujan's question history about "hardware-accelerated t-shirt painting" gave me - somehow - the impression that this question might be of much simpler nature.

So I guess he might simply want to update an existing table ("...I want to update the table with the same name...") such that "the new dataset" will update the existing values ("... only the data will be updated.").

He must have figured out already how to CREATE TABLE and how to INSERT data, and now he is either looking for a

TRUNCATE Foo;
INSERT INTO Foo (col1, col2, ..., coln) VALUES (...);

or a simple

UPDATE Foo
  SET col1 = ..., col2 = ..., ...
  WHERE coln = some condition;


Or he is really after some "out of the box" data historising feature such as the Oracle Flashback Data Archive, available since 11gR2:

  http://www.oracle.com/technetwork/database/focus-areas/storage/total-recall-whitepaper-171749.pdf


By the way Oracle uses since long time internally this "flashback" table space (not sure whether it is really called flashback in this context): that's why a SELECT in Oracle /never/ blocks (unless explicitly specified), because the data coming from different tables is always consistent within the entire query ("statement-level read consistency"); the time stamp of each result is the same, even though it might not be the latest data at this point, in case another session has commited and updated the same data in the meantime:

http://docs.oracle.com/cd/B10500_01/server.920/a96524/c21cnsis.htm#2611



Cheers, Oliver