guest_20040621Все временные характеристики реально будут иметь одинаковый тип timestamp. Вы можете задать precision для типа - и только.Во первых, сколько precision на задавай, СУБД индекс по части атрибута строить не умеет. То есть если важна производительность массированных выборок, включающих условия на частях даты (скажем, год или месяц), никакой precision тут не поможет. Это первое.
Второе. К примеру, MS SQL Server 2000 precision для DATETIME (его аналог timestamp) не поддерживает. Я перерыл BOL, но такого не нашел (если неправ, пусть меня поправят).

softwarer mirВо первых, сколько precision на задавай, СУБД индекс по части атрибута строить не умеет.
Ну это, кстати, не слишком-то верно.
(...)

Уважаемый, вот вам выдержка из BOL (T-SQL):
Как видим, никакого индекса по выражению на столбце В MS SQL Server 2000 нет.
Вы говорите "не люблю неверных утверждений." Слишком смелое заявление.
Если уж взялись меня поправлять, надо было указать, что некоторые СУБД умеют (как частный случай), а некоторые не умеют. Кстати, насколько я знаю, в стандарте SQL-92 ничего не говорится об индексах и о том, как их создавать. Тем не менее можно смело утверждать, что подавляющее большинство СУБД поддерживает индексы на столбцах и лишь некоторые - на выражениях. (Кстати, я в курсе о возможности создания в MSSQL вычислимого столбца, можно об этом не поминать). То есть мое утверждение все же более "общее", чем ваше.

guest_20040621> сколько precision на задавай, СУБД индекс по части атрибута строить не умеет.

Мы не рассматриваем практические аспекты выбора формата хранения атрибутов.

> MS SQL Server 2000 precision для DATETIME (его аналог timestamp) не
> поддерживает.

Насколько я знаю, ни одна из СУБД не поддерживает. ;) Поправьте, если ошибаюсь.
То есть все ваши рассуждения по указанному вопросу можно смело дезавуировать. Вот и чудненько.

guest_20040621> То есть все ваши рассуждения по указанному вопросу можно смело
> дезавуировать. Вот и чудненько.

Откуда это следует, позвольте поинтересоваться?
Ну, напомню, что чисто теоретический аспект я вам разложил по полкам уже давно. Возражений не было. Как перешли к примерам (т.е. практическому аспекту), вы сказали, что таковые вы не рассматриваете. А все ваши высокомудрые рассуждения о precision для datetime вообще, оказывается, оторваны от реалий. Вот и выходит, что толку с ваших постов, как с козла молока :). Чему ж удивляетесь?

guest_20040621АСУ ТП навеяло?А это вы о чем? С каким-то маниакальным упорством их поминаете. Видимо, вам чудится, что это как-то ко мне относится или как-то меня уязвляет... В молоко, внимательный вы наш (для вас это характерно), я АСУ ТП как таковыми вообще не занимаюсь. Или вам нравится в открытую дверь ломиться? :)
guest_20040621я не услышал от Вас вообще ни одного аргумента.Старая песня...
guest_20040621На будущее: если утверждаете что-то, будьте готовы это аргументировать. ;))Хорошо бы вы это поняли когда-либо. К сожалению, до столь же последовательной и развернутой аргументации как у меня вам еще расти и расти. Поэтому вы и «спорите» фразами типа «Тогда это просто ошибочная точка зрения» (ноль обоснований), «Вы делаете распространенную ошибку» (ноль обоснований), «Снова бесполезный пример» (ноль обоснований) и пр. А когда речь зашла о настоящих аргументах, у вас «нет времени описывать всю последовательность рассуждений. Это долго и нудно». Оно и понятно, голословно заявить, что оппонент неправ, легко, а вот обосновать свою позицию — это долго и нудно.
Просто удивительно, как вы приписываете другим свои собственные «грехи»: поверхностные знания и неумение аргументировать.
guest_20040621Hint: знание SQL или конкретной СУБД отнюдь не эквивалентно навыкам проектирования. ;) Рад, что вы начинаете это понимать.

P.S. Вроде только-только перешли от "уколов" в конструктивное русло... Видно, что-то вам неймется. Неужто не устали получать от меня конкретные "плюхи"? Вы что, батенька, мазохист?

2 softwarer
В общем-то, со всем, что в сказали, я согласен. Одна поправка:
softwarer Я полагал, что MSSQL умеет индексировать вычисляемые поля (что, согласитесь, есть ухудшенный вариант индексирования по выражению).Так-то оно так, но поскольку придется создать дополнительно поле

(косяк вышел с отправкой, продолжаю)
Так-то оно так, но поскольку придется создать дополнительно поле, атомарность-то и меняется. То есть формально будет несколько полей, а не одно поле. Что и требовалось доказать (в споре об атомарности).

softwarerА фундаментальные вещи (aka "атомарность") не могут зависеть от прикладных вопросов физической реализации.А вот здесь я бы не согласился.
С одной стороны есть реальный мир, в котором весьма мало «абсолютного», и все довольно относительно. Атомарность ему вообще-то не присуща (я об этом ранее говорил). На другом «полюсе» — конкретная база данных, спроектированная под конкретную задачу. Задача проектирования (в конечном итоге) состоит в отображении реального мира на его модель — БД (еще правильнее сказать на информационную систему, но это опустим). При таком отображении приходится учитывать все ограничения, какие есть: от потребностей заказчика в обработке данных до плюсов и минусов конкретной СУБД. В этих условия некоторая характеристика может быть представлена как атомарным атрибутом, так и набором атомарных атрибутов. Тот же «адрес» для одной задачи всего лишь строка с каким-то там текстом, а для другой — целая «ботва» из номера квартиры, номера дома/корпуса, названия улицы/проспекта/площади/тупика/переулка, названия населенного пункта, страны и все это со ссылками на кучи справочников. Данный пример, бес сомнения, указывает на особенности задачи, но не СУБД. В то же время (вернемся к примеру с датой/временем), если, скажем, выбранная СУБД не позволяет эффективно работать с частями даты/времени, то можно или сменить СУБД (тоже вариант), либо, если это неприемлемо, изощряться по иному. Тут уже скорее учет ограничений СУБД. Согласитесь, трудно проектировать серьезную БД, совсем не учитывая специфику СУБД. То есть можно, но заплатишь чем-то иным, непременно. К сожалению, СУБД весьма отличаются друг от друга, это факт.