[odb-users] RE ODB Help with qualifier ID and object id

[Вячеслав Спиридонов]

We use the second approach. For example с++ code logged the certain
data. That is our code only insert the data
in the table. How the data from the table is read does not interest at
all us. Here table structure:

CREATE TABLE IF NOT EXISTS `log` (
  `DateC` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `UserId` int(10) unsigned NOT NULL,
  `Type` tinyint(3) unsigned NOT NULL,
  `Value` int(11) NOT NULL,
  PRIMARY KEY (`Id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;


As a matter of fact it is possible to consider primary key a set of
DateC, UserId and Type, but such approach has the big redundancy
(overhead). It considerably reduces efficiency of an insertion of the
data in the table. Let's note that it is the main our operation and we
want that it was as much as possible effective. Other variant is
introduction of an additional fictitious field - `Id` bigint(20)
unsigned NOT NULL AUTO_INCREMENT. But this is also overhead.
In the present situation can be the effective decision for indirect
usage may be 2 independent indexes:
DateC  - for samples for a certain interval of time
UserId - for samples on the specific User
But с++ code at all does not concern, its task simply to fill the
table with the data.

Thank for answer.

-----------------------------
> Please give an example the recommended behaviour for a situation when
> there is no necessity for a separate field which contains value object
> id. As qualifier id is obligatory it is necessary to enter redundancy
> into structure of tables for which the concept object id basically is
> not necessary.
--------------------------
There are two possible ways we can support this. The first is to have
an implicit id, for example unsigned long long with auto-assignment
semantics. In this case, while the object does not have the id member,
the table still has the id column (which is also a primary key).

The second approach is not to have the id column either. In other
words, the resulting table will not have a primary key. This is legal
from the database standpoint but somewhat unusual from the the design
perspective.

Which of the above two scenarios do you have?
--------------------------------------------