Novice22 пишет:

> Tovar(
> id int,
> type varchar(*50*)
> )
> Tovar_history(
> id, FK(Tovar.id),
> DateStart,
> DateEnd,
> Name
> )
> id+DateStart - PK Tovar_history
>
>
> Что лучше и эффективней использовать?

2-ой однозначно. Первый ты почти не сможешь обрабатывать запросами.
Т.е. сможешь, но очень сложно.
К тому же это нереляционно - данные в одной записи неявно зависят
от данных в другой записи, поскольку дата начала действия (или конца) записи
лежит в данной записи, а дату конца (или соотв. начала)
действия данной записи ты можешь узнать, только найдя не самым простым
запросом последующую (или соотв. предыдущую ) запись.

(на самом деле конечно не такой он и сложный, но если его вложить
в другие запросы которые уже реально с данными работать будут,
будет совсем невесело).
Posted via ActualForum NNTP Server 1.4

miksoft пишет:

> А дублировать (и не просто дублировать, а следить за непересечением и
> неразрывностью интервалов) данные лучше, что ли?
Вы во-первых сами подняли тему о разрывах. Т.е. это не всегда и нужно.
а во-вторых - да, ЛУЧШЕ следить за этим. Это делается в ОДНОМ запросе
на изменение. А всё остальное надо делать во многих запросах на чтение.
Posted via ActualForum NNTP Server 1.4

ChA пишет:

> Ничуть. Скорее, такая зависимость есть именно во втором случае. В первом
> случае, данные в одной записи никак не зависят от данных в другой
> записи, во всех записях дата начала точки отсчета.

Да зависимость-то есть в любом случае, если она есть в предметной области.
Если один товар "сменяет" другой - они зависимы. Вопрос в том, как эту
зависимость более удобно представить в БД.

А вот во втором
> случае, данные в одной записи как раз зависят от данных в другой записи,
> так как подразумевается, если я правильно понял, непересекающиеся
> промежутки.

Там в обоих случаях либо есть эти промежутки, либо нет. Только в
первом конец или начало промежутка находится в соседней записи.

И если меняем, например, дату конца периода в первой записи,
> то обязательно надо корректировать дату в следующей, второй по порядку,
> записи.

Ну, конечно вы правы. Тут можно покрасивее нарисовать, но будет немного
сложнее. Но первый вариант совсем плохой. Ну т.е. запросы будут сложные--
напишите запросы реальные, попробуйте.

Хуже того, при неверном указании даты окончания в одной записи,
> все последующие могут оказаться в противоречивом состоянии, когда дата
> их окончания неожиданно станет меньше даты окончания первой записи. Но и
> это еще не все, во втором случае еще и появляется зависимость между
> полями. Значение в одном из них обязательно должно превышать значение в
> другом, и наоборот. Таким образом, именно второй случай следует считать
> проявлением нереляционности, а точнее, денормализации, выполняемый с
> целью оптимизации некоторых видов запросов.

вы во-первых путаете денормализацию и ненормализованность,
а во-вторых, говорите вообще ерунду. Кортежи нормализуются независимо
друг от друга - вся таблица целиком нормализуется. Функциональная зависимость--
это отношение между полями таблицы. У КАЖДОГО товара должен
быть срок его действия. Есть товар. Есть о нём запись в таблице(ах).
Все данные ЭТОГО товара должы быть самодостаточными для приложения.
Все остальные товары я могу удалить напр. Вот понадобится мне
почистить эту таблицу истории -- и КАК ? Последнюю запись перед
первой удаляемой придётся оставить, так ? Придётся. Но она БУДЕТ
НЕВАЛИДНОЙ, потому что срок начала её действия будет находится
в предыдущей удалённой записи. Тут пример немного надуманный, правда,
потому что можно считать дату в записи датой начала действия записи,
и тогда всё как бы в порядке. Но в общем это всё равно -
с такими проблемами вы всегда будете встречаться, если будете
раскладывать данные одной записи по нескольким.

> P.S. То, что любой факт должен меняться только в одном месте, является
> косвенным признаком нормальности решения модели.

Нет. Здесь нет никакой ненормальности. Это -- бизнес логика в
чистом виде -- вам нужно чтобы периоды сроков действия товаров не
пересекались.
Posted via ActualForum NNTP Server 1.4

korda пишет:

> Я уже было решил, что буду использовать второй вариант, но теперь увидев
> эту тему и Ваш ответ засомневался в правильности выбора.
> В свое время Вы написали примеры запросов ко второму варианту. См.:
> http://sql.ru/forum/actualthread.aspx?tid=599398
> Не могли бы Вы написать, как будет выглядеть запрос для превого варианта?

вот именно. Надо написать список нужных запросов и попытаться реализовать
их в двух вариантах. Потом посмотреть, какой лучше. Я вас уверяю, второй
выиграет.
Posted via ActualForum NNTP Server 1.4

miksoft пишет:

> Для выборок по индексу - очень неудачное решение. Имхо, лучше
> использовать константы, гарантированно выходящие за диапазон
> обрабатываемых данных.

Да не пугайте народ. Ничего страшного.
Posted via ActualForum NNTP Server 1.4

KOT MATPOCKuH пишет:

> Можно выбрать промежуточный вариант: структура - как во 2 варианте, но
> пользователь может корректировать только поле DateStart. Триггер пусть
> корректирует поле DateEnd в соответствующих записях. Результат: простота
> заполнения 1 варианта, простота выборок 2 варианта, отсутствие проверок
> корректности 1 варианта + триггер нада написать.

Так , стоп.

Тут надо разобраться периоды могут пересекаться, или нет.
Если могут - тогда их вообще редактировать свободно можно
и не будет никакой логики непересечения.

Если не могут, то вопрос, будут ли дырки или нет.
Если нет, то это вообще бизнес-операция должна быть - замена
одного товара на другой. Ставим в старом дату конца, ставим
в новом дату начала +1 день.

Вообще, ещё раз, это бизнес-логика в чистом виде.
Posted via ActualForum NNTP Server 1.4