Вопрос заключается в следующем:
Есть клиенты которые делают заказы.
При вводе даты заказов оператором нужно ли привязываться к текущему времени на сервере, типа чтобы нельзя было например ввести заказ задним числом... ?
Хелп ми!!!

Alexander PopovЭто скорее вопрос не к Проектирование БД, а к бизнес процессам принятым в компании. Если это допускается то почему нет.

У меня этот вопрос возник скорее не из того чтобы ограничить возможность ввода задним числом, а из за того что мне непонятно как нужно отделять историю заказов от текущих заказов...???

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

как бы вы отделили историю заказов от текущих и будущих заказов, и нужно ли это делать ?

softwarerЕстественное для заказа понятие - состояние. "Выполнен", "выполняется", "оплачен", "готов к выполнению" и так далее. Все описанное - вполне в это ложится.

Дальше - можно смотреть. Например, завести для выполненных и прочих "архивных" заказов отдельную партицию.

т.е. заказы которые ещё не выполнены - будут находится в одной таблице(оперативные данные),

а заказы которые уже выполнены - в другой таблице - для дальнейшего OLAP анализа...

Вы это хотите сказать ?

а обязательно ли вообще отделять текущие заказы от выполненных в 2 разные таблицы, можно же просто всё в одной таблице с полем выполнен/выполняется... ???

softwarer а обязательно ли вообще отделять текущие заказы от выполненных в 2 разные таблицы, можно же просто всё в одной таблице с полем выполнен/выполняется... ???
Я специально употребил термин "партиция" - очень удобный механизм. Если партиций нет - надо думать, какое решение будет более удобным. Я бы сказал, стоит держать в одной таблице, пока объем исторических данных не станет мешать в оперативной деятельности.

1. а что такое партиция что это за механизм ?
2. очень интересный момент!!! :
Допустим в в оперативной таблице у нас хранится какаято часть истории...
(за 2 года...например) нам клиент говорит... хочу выполнить заказы тамже где и в прошлый раз...
а прошлый раз мог быть когда угодно... 2 года назад или 10 лет назад...
нужно ли делать поиск в истории, или его нужно делать только в пределах моих 2-х лет(или 5 лет...) ?

Shtock

ясно, т.е. это чтото типа механизма кот позволяет прозрачно для SQL запросов исключать и подключать разные части таблицы, я правильно понял.. ?

и ещё... если я сейчас небуду заморачиваться с партициями, а просто оставлю 1 таблицу с заказами... т.е. вся история заказов будут тамже где и оперативные данные...
потом когда через года 3 там будет дофига записей, можно будет безболезненно добавить партиционирование, или это нужно обязательно сразу продумать ?

softwarer sql20005потом когда через года 3 там будет дофига записей, можно будет безболезненно добавить партиционирование, или это нужно обязательно сразу продумать ?
Для добавления партиций в непартиционированную таблицу достаточно на несколько минут исключить доступ к этой таблице (независимо от размера). Добавление новых партиций - полностью on-line операция.

Этож получается панацея от всех бед какая то...
1. Во первых: ненужно просматривать все данные в огромной таблице можно просто сделать запрос который будет просматривать записи только одной маленькой партиции(10000 записей например)
2. во вторых: ненужно ничего лишнего предусматривать для версионности... и истории, просто не удалять а делать пометку неактивный - вот и вся версионность... или история... - т.е. DML мы не переделываем
3. В третьих: ненужно на этапе проектирования продумывать хранилище данных для например таблицы данных и способы агрегатирования и архивации, т.к. в любой момент можно зделать партиционирование, и убрать из оперативной обработки лишние данные, а хранилище потом когда угодно можно спроектировать...

Я сделал правильные претположения ?

Круто!!! а я уже было хотел вешатся на этапе проектирования ведь сложно предусмотреть аналитическую обработку и всё такое... особенно когда сроки поджимают...

Теперь отложу разработку OLAP, и со спокойной совестью буду делать своё OLTP, имея ввиду что все статистические данные не удаляются а помечаются как не активные.

Огромное Спасибо!!!

softwarer sql20005Теперь отложу разработку OLAP, и со спокойной совестью буду делать своё OLTP
Вы только сначала убедитесь, что у Вас партиции есть :)

вы имеете ввиду что не во всех СУБД есть партиции ??? - у меня Oracle...

Блин!!! ещё одна проблема вырисовывается!!!
а как делать собственно удаление строк ???
я вижу 2 варианта:
вар1: во всех!!! таблицах добавить поле deleted типа boolean - но это както очень некрасиво.
вар2: сделать одну таблицу - карзина many to many, и в ней указывать идентификаторы всех удалённых строк для всех таблиц базы данных.
затем, в условия выборок каждой записи из всех таблиц включать проверу
есть ли такая строка в корзине.
но я представляю размер такой таблицы.... он может теоретически быть громадным, ведь это проекция всех таблиц на одну таблицу...

а как вы делаете удаление записей ?

softwarer
Еще и не во всех редакциях Oracle...


Что в Standart eddition One, и в Standart Eddition для 9-ки - нету ?, только в
Enterprice ?

softwarer
В абсолютном большинстве случаев (известных мне) из базы почти ничего не удаляется. Как только с записью происходило что-то интересное - ее и по бизнесу, и по реализации удобнее зафиксировать навсегда (возможно - в архив). Удаляются только записи статуса "простая бумажка" - например, ошибочно введенные, или те, где клиент сразу же отменил заказ.


1. да... а как определить например оператор ввёл по ошибке клиента, и удалил потом его физически, или просто удалил старого клиента ?
или если он случайно ввёл(всмысле транзакция прошла) то уже всё, это навсегда?
Т.е. прога же незнает что есть ошибочно введённые данные, а что не ошибочно... и какие заказы сразу отменились а какие не сразу...
как с этим быть ?
2. как быть с удалением/восстановлением и с master/detail, т.е. например если мы логически удаляем master... ???

softwarer
В абсолютном большинстве случаев (известных мне) из базы почти ничего не удаляется. Как только с записью происходило что-то интересное - ее и по бизнесу, и по реализации удобнее зафиксировать навсегда (возможно - в архив). Удаляются только записи статуса "простая бумажка" - например, ошибочно введенные, или те, где клиент сразу же отменил заказ.


Я логическое удаление представляю примерно так:
1. в каждой таблице существует отдельное поле deleted.
2. на каждой таблице присутствует дополнительный триггер кот срабатывает
при изменении этого поля deleted. (т.е. 50 таблиц - 50 доп. триггеров для лог удаления)
3. При срабатывании триггера, он просматривает нет ли дочерних записей во всех возможных таблицах, и если есть то или запрещает удаление, или меняет все соотв поля в дочерних записях..., т.е. это достаточно медленно, и фактически повторение стандартных правил целостности данных при удалении...
4. Вместо таблиц используются вьюхи которые фильтруют deleted записи.
Както всё это сложно(п2,п3), может есть какойто более правильный и простой путь, подскажите... ?

softwarer
Это должен определить сам оператор - и по результатам нажать "Удалить" либо "Перенести в архив". А программа должна не позволить удалить клиента, с которым уже происходило что-то интересное - в простом варианте просто благодаря наличию ссылок на этого клиента (foreign keys, например, из заказов).


здесь проблема следующая... не все операторы наверное должны иметь доступ к возможности физического удаления!!!
- это принципиальный момент как мне кажется.
и вот если оператор неимеет такой возможности, он ввёл чтото неправильно, потом удаляет... а прога незнает нужно удалить или нужно пометить... поетому она всегда помечает!!!
еслиже юзер имеет и кнопочку удалить и кнопочку пометить, то это уже не то...
важно ведь именно чтобы юзер мог всегда восстановить данные!!!, т.е. у него нету средств удаления - это принципиально если делать лог удаления.
Нужно понятие карзина, из которой всегда можно вытащить записи.

softwarer
"Какие отменились сразу, а какие не сразу" - прога знает. Логика в каждом случае может быть разной, нужно смотреть по месту. Для документов обычный вариант - стартовое состояние "просто бумажка"; только в этом состоянии документ может быть физически удален, и как правило - если документ переведен в другое состояние, вернуться в это он уже не может.
[/ quot]
несовсем понятен термин просто бумажка...
если док является бумажкой до того как к нему прикреплены дочерние сущности то это одно, тогда понятно и прога знает что его можно удалять т.к. он нисчем несвязан...
но опятьже логики здесь будет для каждой таблицы и разной при удалении просто дохрена!!!

[quot softwarer]
Зависит от бизнеса. Вариантов в принципе два: либо "логически удалить детали", либо "оставить детали как есть" - все равно до них не доберешься.

Удалять скорее всего нельзя, примеров море при удалении корпорации нельзя удалять все её торговые точки...
Ничего не делать - если это просто тихо удалить то это неверно, т.к. юзеры потом долго плеваться будут почему у меня владелес точи компания сусел мыже удалили её 3 года назад...
если это всмысле запрет удаления, или какаято замена, тогда правильно но опятьже проверять все дочерние таблицы это ужасно!!! - для каждой таблицы проверять все дочерние...

softwarer
В целом, я бы избегал мысли о "логическом удалении". "Состояние" - это более универсальная и более удобная метафора.


согласен но потход же неменяется как её назвать:-)

а нужно то:
1. корзина(т.е. страховка от случайного удаления)
2. скрытие данных которые ненужны, но которые нельзя удалять, так как они используються гдето в отчётах...

можно както это просто сделать ?, ато я вижу только сложное решение -
см мой предыдущий пост ???

там в средней цитате ответ прошол ;-|...