Seloa Elic[quot ЮВ]СУБД ЛИНТЕР. Псевдостолбец ROWTIME хранит время создания записи.
..............
P.S. Типа этот ROWTIME абсолютно уникальный?


Ох и не повезёт по жизни тому, кто так будет считать. Даже если и в одном поясном времени работает.


Объясните, мне это интересно.
Если я добавляю записи с интервалом, скажем, 5-10 мин (заявки), то почему ROWTIME не будет уникальным ?
Я допускаю не уникальность ROWTIME (хотя не знаю, что гарантируют разработчики в данном случае) если, скажем, в 1 сек добавляю 100 записей.

Seloa
Если вы работаете, и давно, у вас уже должен появиться нюх на проблемы.


А если работаю недавно, то нюх на проблемы не обязателен ? Странная логика. Ну, да ладно.


Seloa
И желание искать риски у нововведений. К примеру ответ на такой вопрос - как себя поведёт ваше нововведение при синхронизации времени серверов, или при сбое на нём - батарейки ведь не самая надёжная и необходимая вещь в компьютере ;).
Еще интереснее будет при переходе зимнее-летнее время.



К этому списку проблем я могу добавить и другие подводные камни:
1 например, предположим, что вы разработали правильный алгоритм выборки 20 последних записей, но может случиться так, что пока они выбираются, придет новая “последняя” запись и возникнет желание включить и ее в выборку – начнете процесс сначала. Не закончив его можно, получить еще одну “последнюю” запись и т. д. – будет вечная догонялка как в логическом парадоксе Зенона про бегуна Ахилла и черепаху, которую он никогда не сможет догнать.

2 Можно пренебречь, что ROWTIME у некоторых записей будет одинаковым. Это некритично только для первых записей выборки и становится критичным на границе выборки. Т.е.пусть надо выбрать 20 последних записей и записи R19, R20, R21, R22 получили равный ROWTIME. Тогда при сортировке (в зависимости от используемого алгоритма) может оказаться такое расположение записей R22, R21, R20, R19. И в первую двадцатку попадут другие записи.
И др. примеры.
К чему я это пишу ?
К тому, что любая проблема должна начинаться, как говорят в медицине, с анамнеза – обследования больного. И только потом выносится вердикт: “Будем лечить или сразу в морг”.

Понятно, что методы решения проблемы, когда записи в таблице обновляются одновременно с 100 терминалов или раз в неделю с пакетном режиме – совершенно различны (а одном дефект бизнес-логики, в другом случае проблема вполне решаема).

Поэтому я соглаcен, что нельзя слепо следовать советам типа “Этого нельзя делать ни в коем случае” или “Используйте ROWTIME и не заморачивайте себе голову”.


Теперь от практических вопросов – к теоретическим.
Есть такая группа исполнителей (кажется ЧиЖ ), которые поют “А не сочинить ли мне песню о любви ?” . На что им из зала резонно отвечают: “Не надо”.
Аналогично, если бы разработчики СУБД спросили участников форума, нужны ли в БД ROWTIME (как в Линтере) , timestamp (в других СУБД), они тоже услышали бы дружный хор “Не надо” (судя по форуму).
Тем не менее разработчики пренебрегли советом и ввели эти значения.
Чем они руководствовались в своем упрямстве?
Варианты:
1 ROWTIME нельзя использоваться для идентификации временной последовательности записей (тогда смысл его введения);
2 Использовать “можно, но осторожно”;
3 ROWTIME предназначен для внутреннего использования СУБД и пользователи использовать не должны;
4 Другие соображения

Поэтому хотелось бы услышать мнение разработчиков по этой теме.
Как писал Мимопроходящий в другой теме:

хотелось бы заслушать также, начальника транспортного цеха. (С)
pavelp, просим, просим...

Seloa
И желание искать риски у нововведений.


Наоборот, желание понять и узнать, как можно применить нововведение.