Здравствуйте, paucity, Вы писали:
P>Господа!
P>Чем плохо и насколько плохо наличие в составном первичном ключе поля типа дата-время?
P>СУБД: Oracle, MS SQL 2000/2005/2008
P>Спасибо!
В MS SQL 2000/2005/2008 ничего плохого не замечено
Здравствуйте, BlackEric, Вы писали:
BE>Здравствуйте, paucity, Вы писали:
P>>Господа!
P>>Чем плохо и насколько плохо наличие в составном первичном ключе поля типа дата-время?
P>>СУБД: Oracle, MS SQL 2000/2005/2008
P>>Спасибо!
BE>В MS SQL 2000/2005/2008 ничего плохого не замечено.
Единственное это то, что дата не всегда может быть уникальной, как и время.
Здравствуйте, paucity, Вы писали:
P>Чем плохо и насколько плохо наличие в составном первичном ключе поля типа дата-время?
Тут есть подводный камень.
Многие платформы дату хранят в виде double, совсем не факт, что при чтении первичного ключа не возникнет некое округление. В результате чего, имея на руках ключ прочитанный из базы можно получить 0 после выполнения такого запроса:
select count(*) from tbl t where t.time = @time
Т.е. мы теряем саму суть первичного ключа, т.к. не можем идентифицировать запись.
Собственно, почему возник вопрос:
Насколько я знаю, тип даты внутренне представлен как количество миллисекунд, прошедших от какой-то нулевой даты. Таким образом, на каждую календарную дату приходится порядка 86400000 значений миллисекунд.
Собственно это — 86400000 значений на один календарный день — и вызывает сомнения в целесообразности индексации по полю типа дата, особенно если критерии выборки в основном основаны только на дате, а не на дате-времени:
… WHERE field_date = 14/10/2009
А не
… WHERE field_date = 14/10/2009 10:45:15:16
Или у меня косяк в рассуждениях?
Практическое приложение первоначального вопроса:
Чтобы отслеживать последовательность состояний чего-либо, какую структуру предпочтительнее использовать с точки зрения производительности и прочих подводных граблей?
1)
CREATE TABLE T (
ID_anything int NOT NULL, /*PK*/
Time_Changed date NOT NULL, /*PK, время перехода в новое состояние*/
State_anythinq int NOT NULL/* значение состояния */
)
2)
CREATE TABLE T (
ID_anything int NOT NULL, /*PK*/
Sequence_number int NOT NULL, /*PK, sequence*/
State_anythinq int NOT NULL/*время перехода в новое состояние*/
Time_Changed date NOT NULL/* значение состояния */
)
Здравствуйте, paucity, Вы писали:
P>Спасибо!
P>Собственно, почему возник вопрос: P>Насколько я знаю, тип даты внутренне представлен как количество миллисекунд, прошедших от какой-то нулевой даты. Таким образом, на каждую календарную дату приходится порядка 86400000 значений миллисекунд.
P>Собственно это — 86400000 значений на один календарный день — и вызывает сомнения в целесообразности индексации по полю типа дата, особенно если критерии выборки в основном основаны только на дате, а не на дате-времени: P>
… WHERE field_date = 14/10/2009
P>А не P>
… WHERE field_date = 14/10/2009 10:45:15:16
P>Или у меня косяк в рассуждениях?
P>Практическое приложение первоначального вопроса: P>Чтобы отслеживать последовательность состояний чего-либо, какую структуру предпочтительнее использовать с точки зрения производительности и прочих подводных граблей? P>1) P>
P>CREATE TABLE T (
P>ID_anything int NOT NULL, /*PK*/
P>Time_Changed date NOT NULL, /*PK, время перехода в новое состояние*/
P>State_anythinq int NOT NULL/* значение состояния */
P>)
P>
P>2) P>
P>CREATE TABLE T (
P>ID_anything int NOT NULL, /*PK*/
P>Sequence_number int NOT NULL, /*PK, sequence*/
P>State_anythinq int NOT NULL/*время перехода в новое состояние*/
P>Time_Changed date NOT NULL/* значение состояния */
P>)
P>
P>Первый или второй вариант?
лучше третий вариант:
CREATE TABLE T (
Sequence_number int NOT NULL, /*PK, sequence*/
ID_anything int NOT NULL, /*FK*/
Time_Changed date NOT NULL, /*IX, время перехода в новое состояние */
State_anythinq int NOT NULL/* значение состояния */
)
индексация по дате нужна в любом случае, если запросы идут по дате.
вопрос в другом — за одну дату могут быть несколько изменений состояния?
Здравствуйте, DmitryV, Вы писали:
DV>лучше третий вариант: DV>
CREATE TABLE T (
Sequence_number int NOT NULL, /*PK, sequence*/
ID_anything int NOT NULL, /*FK*/
Time_Changed date NOT NULL, /*IX, время перехода в новое состояние */
State_anythinq int NOT NULL/* значение состояния */
)
DV> DV>индексация по дате нужна в любом случае, если запросы идут по дате. DV>вопрос в другом — за одну дату могут быть несколько изменений состояния?
Да, может быть несколько изменений
Здравствуйте, paucity, Вы писали: P>Насколько я знаю, тип даты внутренне представлен как количество миллисекунд, прошедших от какой-то нулевой даты.
Не совсем. Дата P> Таким образом, на каждую календарную дату приходится порядка 86400000 значений миллисекунд.
Нет. Из-за того, что дата представлена с плавающей запятой, "плотность" значений на календарную дату сильно зависит от самой даты.
См. accuracy в http://technet.microsoft.com/en-us/library/ms187819.aspx
P>Практическое приложение первоначального вопроса: P>Чтобы отслеживать последовательность состояний чего-либо, какую структуру предпочтительнее использовать с точки зрения производительности и прочих подводных граблей? P>1) P>
P>CREATE TABLE T (
P>ID_anything int NOT NULL, /*PK*/
P>Time_Changed date NOT NULL, /*PK, время перехода в новое состояние*/
P>State_anythinq int NOT NULL/* значение состояния */
P>)
P>
P>2) P>
P>CREATE TABLE T (
P>ID_anything int NOT NULL, /*PK*/
P>Sequence_number int NOT NULL, /*PK, sequence*/
P>State_anythinq int NOT NULL/*время перехода в новое состояние*/
P>Time_Changed date NOT NULL/* значение состояния */
P>)
P>
P>Первый или второй вариант?
create table Changes
(
ID int identity not null primary key, -- последовательность определяется этим полем.
TargetID int not null foreign key references Target(ID),
ChangeDate datetime not null,
NewState int
)
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
paucity пишет:
> Насколько я знаю, тип даты внутренне представлен как количество > миллисекунд, прошедших от какой-то нулевой даты. Таким образом, на > каждую календарную дату приходится порядка 86400000 значений миллисекунд.
По крайней мере в контексте указания в топике нескольких СУБД это утверждение
неверно.
> Или у меня косяк в рассуждениях?
Здравствуйте, wildwind, Вы писали:
P>>Чем плохо и насколько плохо наличие в составном первичном ключе поля типа дата-время?
W>предлагаю сначала рассмотреть вопрос "Чем плохо и насколько плохо наличие составного первичного ключа"
