Здравствуйте, Jester, Вы писали:

J>То есть, если есть 4 параметра, которые могут изменяться независимо, потребуется 4 вспомогательных таблицы? И как при такой структуре собирать объект на некоторый момент времени?

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

J>Реже, конечно, но не так уж редко, чтобы этими запросами можно было пренебречь. Отдельный таблспейс? Это можно, через секционирование, но что значит "убирать"? Крутить job, который будет делать delete/insert?

я имел в виду сразу создавать эти таблицы в отдельном tablespace.

C0s>>вообще говоря, я еще предпочитаю добавлять к каждой группе исторических атрибутов номер версии (как в головной таблице, так и в исторических, причем в последних он становится частью PK, а в головной по нему можно сделать констрейнт уникальности), чтобы во всех случаях, где требуется ссылка на конкретное состояние объекта в прошлом можно было делать выборку по номеру версии (т.е. используя в джойне ключи вместо сравнения дат)

J>Что-то очень сложное получается. Есть подозрение, что производительность будет проседать.

давай посмотрим.
в моем варианте я вижу, что для проведения операции изменения состояния объекта надо считать его актуальное состояние + последнюю запись из истории, которую надо будет закрыть (select по PK с джойном по уникальному ключу). далее меняем поля (update в главной таблице по PK), закрываем историческую запись (update по PK) и создаем новую историческую запись (insert).
в варианте без исторической таблицы все зависит от наличия номера версии (пока было непонятно из дискусии, присутствует такое или только даты периодов). с ним для выборки потребуется сделать (select по PK и доп. условию, определяющему последнюю версию — флаг там или null в каком-нибудь поле), далее сделать update этой записи (по уникальному ключу, в котором участвует номер версии) и сделать insert новой записи
без номера версии и без исторической таблицы, делая выборки при операциях только на основе дат вообще вижу одно большое заднее место

что касается последующих выборок, то я не вижу большой разницы в selectе из одной таблицы и в selectе с джойном по части уникального ключа. понятно, что второе медленнее, но разговор-то не только об аспекте быстродействия в runtime, а о том, что у каждого подхода при оценке по разным направлениям обнаруживаются свои достоинства и недостатки.
а вообще, в процессе проведения операции изменения все равно приходится много чего селектить для проверки правильности проведения операции, поэтому экономить на одном селекте ценой отказа от ключей — как-то странно...

J>В идеале можно все сделать хорошо и красиво. Нормализованные таблицы, констрейнты... В реале же приходится и денормализовать порой, и от констрейнтов отказываться...

это как раз понятно и нормально. не видел бы никаких проблем, если какая-то информация для повышения эффективности биллинга в некотором варианте при операции изменения состояния объекта также дополнительно сохранялась бы в структурах данных, максимально приближенных к лицевым счетам или биллинговым периодам на контрактах (или что там в CBOSS в качестве центра притяжения данных)

Здравствуйте, Аноним — Astellar, Вы писали:

А>Навскидку, я сделал бы так примерно:

выкинул все лишнее:

А>table department_hist(depHist_id (PK),dep_dep_id(FK), start_date, end_date, ...)

А>table emplpoee_hist(emp_emp_id (FK), start_date, end_date, depHist_depHist_id(FK), ...)

— это как раз то, что я имел в виду под "размножением данных в таблицах"

Автор: PNCHL
Дата: 16.01.06

. Если происходят какие-то изменения "подразделения", возникает новая запись в dept_hist — с новым depHist_id. Для того, чтобы с момента изменения подразделения, "сотрудник" начал ссылаться на новую запись в dept_hist, придется добавить новую запись и в emp_hist — со ссылкой на новый depHist_id. В конечном итоге получится, что при изменении объетка нужно делать новую запись в истории всех ссылающихся на него. По-моему,это не очень хорошо

Здравствуйте, PNCHL, Вы писали:

PNC>Пример, если у нас создана таблица с ограничением на столбец not null:
PNC>то для того, чтобы выяснить сколько в таблице записей с ПУСТЫМ ID

PNC>  create table t1(id number not null)

PNC>  select count(*)
PNC>  from t1
PNC>  where id is null

PNC>совершенно необязательно лезть в таблицу, можно на основе констрейнта сразу сказать, что таких записей нет. Однако Oracle этого не делает — он честно лезет в таблицу и все подсчитывает.

с указанным предусловием (id not null) вероятность появления подобного запроса в коде вменяемого программиста равна 0. имхо вряд ли oracle будет что-то писать для академическо-клинических случаев

Здравствуйте, Аноним, Вы писали:

А>Вот это и есть корень непонимания.
А>Когда Вы решаете затачу расчета стоимости услуги, оказанной в прошлом, Вы не можете полагаться на "актуальные" версии. Вам нужны именно те условия обслуживания абонента, которые действовали в момент оказания услуги. Не раньше и не позже.
А>Для биллинговой системы это основной прецедент.

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

А>Отсюда и модель реализации версионности.

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

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

Здравствуйте, PNCHL, Вы писали:

PNC>

PNC>выкинул все лишнее:

А>>table department_hist(depHist_id (PK),dep_dep_id(FK), start_date, end_date, ...)

А>>table emplpoee_hist(emp_emp_id (FK), start_date, end_date, depHist_depHist_id(FK), ...)

PNC>

PNC>- это как раз то, что я имел в виду под "размножением данных в таблицах"

Автор: PNCHL
Дата: 16.01.06

. Если происходят какие-то изменения "подразделения", возникает новая запись в dept_hist — с новым depHist_id. Для того, чтобы с момента изменения подразделения, "сотрудник" начал ссылаться на новую запись в dept_hist, придется добавить новую запись и в emp_hist — со ссылкой на новый depHist_id. В конечном итоге получится, что при изменении объетка нужно делать новую запись в истории всех ссылающихся на него. По-моему,это не очень хорошо

из employee_hist должна идти ссылка на department(id), мне вообще странно представить, что история изменения атрибутов департамента имеет какое-то отношение к сотруднику.
при этом я не вижу, какие срезы данных нам становятся недоступными. или я что-то проглядел?

Здравствуйте, C0s, Вы писали:

C0s>Здравствуйте, Jester, Вы писали:

J>>То есть, если есть 4 параметра, которые могут изменяться независимо, потребуется 4 вспомогательных таблицы? И как при такой структуре собирать объект на некоторый момент времени?

C0s>вообще говоря, надо смотреть от операции изменения. если все четыре параметра идут ее атрибутами вместе — я считаю, что они меняются вместе. по моему опыту редко встречаются классы бизнес-объектов, над которыми требуется много разных операций изменения состояния.

Насчет "много" — это отдельный вопрос. А насчет "разных" — это бывает. Если каждый из 4 параметров может меняться независимо, но с вероятностью 0.01% за полгода — таблицу отдельную можно не создавать?

J>>Что-то очень сложное получается. Есть подозрение, что производительность будет проседать.

C0s>давай посмотрим.
C0s>в моем варианте я вижу, что для проведения операции изменения состояния объекта надо считать его актуальное состояние + последнюю запись из истории, которую надо будет закрыть (select по PK с джойном по уникальному ключу). далее меняем поля (update в главной таблице по PK), закрываем историческую запись (update по PK) и создаем новую историческую запись (insert).

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

C0s>в варианте без исторической таблицы все зависит от наличия номера версии (пока было непонятно из дискусии, присутствует такое или только даты периодов). с ним для выборки потребуется сделать (select по PK и доп. условию, определяющему последнюю версию — флаг там или null в каком-нибудь поле), далее сделать update этой записи (по уникальному ключу, в котором участвует номер версии) и сделать insert новой записи
C0s>без номера версии и без исторической таблицы, делая выборки при операциях только на основе дат вообще вижу одно большое заднее место

Очень даже просто. Добавляется конструкция вида '<some_date> between from_date and to_date'. (Затем это очень неплохо можно секционировать по from_date.) При апдейте объекта апдейтится to_date старой версии и инсертится новая версия.

C0s>что касается последующих выборок, то я не вижу большой разницы в selectе из одной таблицы и в selectе с джойном по части уникального ключа. понятно, что второе медленнее, но разговор-то не только об аспекте быстродействия в runtime, а о том, что у каждого подхода при оценке по разным направлениям обнаруживаются свои достоинства и недостатки.

Возможно. Только при выборе атрибутов объекта на некоторый момент времени необходимо будет искать по дате в КАЖДОЙ исторической таблице и джойнить их друг с другом и с актуальной.

Здравствуйте, Jester, Вы писали:

J>>>То есть, если есть 4 параметра, которые могут изменяться независимо, потребуется 4 вспомогательных таблицы? И как при такой структуре собирать объект на некоторый момент времени?

C0s>>вообще говоря, надо смотреть от операции изменения. если все четыре параметра идут ее атрибутами вместе — я считаю, что они меняются вместе. по моему опыту редко встречаются классы бизнес-объектов, над которыми требуется много разных операций изменения состояния.

J>Насчет "много" — это отдельный вопрос. А насчет "разных" — это бывает. Если каждый из 4 параметров может меняться независимо, но с вероятностью 0.01% за полгода — таблицу отдельную можно не создавать?
J>Последняя запись из истории будет собираться из нескольких таблиц. Это раз. При смене сразу нескольких атрибутов может потребоваться запись в несколько исторических таблиц. Это два.

я не случайно написал про операцию изменения. чуть более сухим языком:

если имеем для изменения объектов типа A операцию updateObjectA(pk, a1, a2, a3, a4), то a1, a2, a3, a4 — это взаимосвязанные атрибуты. для меня это значит, что одной таблицы истории достаточно

если же имеем две операции для обновления объектов того же типа update1ObjectA(pk, a1, a2) и update2ObjectA(pk, a3, a4), то, скорее всего, a1,a2 я положу в одну таблицу историй, a3,a4 — в другую. при этом ситуацию, когда попросят добавить update3ObjectA(pk, a1, a3) буду рассматривать как недостаточно проработнные требования.

а в целом, сам факт разделения a1,a2 от a3, a4 на уровне требований, для меня значит, что запросы соединяющие a1,a2,a3,a4 вместе будут маловероятными
то бишь, к примеру (более-менее абстрактному), если мне надо услугу, оказываемую абоненту на регулярной основе, и мне важен статус абонента на определенный момент времени, но вообще не волнует его адрес, то в историю статусов абонентов я полезу, а в историю его адресов — нет

J>Очень даже просто. Добавляется конструкция вида '<some_date> between from_date and to_date'. (Затем это очень неплохо можно секционировать по from_date.) При апдейте объекта апдейтится to_date старой версии и инсертится новая версия.

т.е. OR с двумя сравнениями по неиндексированным полям лучше, чем джойн по уникальному ключу? возможно....

C0s>>что касается последующих выборок, то я не вижу большой разницы в selectе из одной таблицы и в selectе с джойном по части уникального ключа. понятно, что второе медленнее, но разговор-то не только об аспекте быстродействия в runtime, а о том, что у каждого подхода при оценке по разным направлениям обнаруживаются свои достоинства и недостатки.

J>Возможно. Только при выборе атрибутов объекта на некоторый момент времени необходимо будет искать по дате в КАЖДОЙ исторической таблице и джойнить их друг с другом и с актуальной.

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

Здравствуйте, C0s, Вы писали:

C0s>мой анализ виденных систем показывает, что все-таки имеет смысл историю писать именно для историй (визуализаций, разбора полетов и т.п.). а для эффективных вычислений продумывать дополнительные структуры данных, т.е. отделять их от данных для поддержания операций. тогда можно было бы реализовывать событийные (или квазисобытийные) подходы обработки данных и, как следствие, выделение биллинга как модуля из операционной части (вплоть до использования отдельной БД)

Если под "эффективностью вычислений" понимать производительность, то, как я уже писал

Автор: C0s
Дата: 17.01.06

, можно выделить актуальные данные в отдельную секцию и работать с ней практически также, как с отдельной таблицей. Единственный минус — потребуется обязательно использовать Oracle Enterprise Edition, что недешево, но речь сейчас не об этом...

Если под "событийностью" вы понимаете навешивание обработчиков на триггеры таблицы с актуальными данными, то при желании можно применять этот подход и для одной таблицы, хранящей и историю и актуальные данные. Нужно просто сделать VIEW, отбирающую только актуальные данные и навешивать обработчики событий на INSTEAD OF триггеры, которые будут подменять update в VIEW на insert новой записи в историю и update end_date в текущей записи.
Я, однако, считаю, что вместо использования триггеров лучше делать API — функции для выполнения основных операций над объектами и уже в эти функции встраивать вызовы обработчиков событий...


C0s>кстати, я не писал, что эти таблицы обязательно должны иметь одинаковую структуру. более, предлагал, что разную. вариант Astellar

Автор:
Дата: 16.01.06

чем-то близок

По поводу "варианта Astellar", я уже ответил

Автор: C0s
Дата: 17.01.06

. Он требует создания дополнительных записей в истории объектов, которые не менялись...

Здравствуйте, C0s, Вы писали:

C0s>это как же постановщики требований должны промывать разработчикам мозги, что из вполне нормального требования "правильно рассчитвать стоимость услуги в зависимости от статуса абонента и статуса самой услуги (а также других параметров, влияющих на ее стоимость)" выходит требование "делать такую реализацию версионности".

Из неполноты представленного Вами варианта "нормального" требования действительно сложно
Но попробуйте дополнить:
"правильно рассчитвать стоимость услуги в зависимости от статуса абонента и статуса самой услуги (а также других параметров, влияющих на ее стоимость), ДЕЙСТВОВАВШИХ НА МОМЕНТ ОКАЗАНИЯ УСЛУГИ" — и все станет гораздо интереснее

C0s>я к тому клоню, что в норме реализацию выбирают разработчики, а в данном случае она не единственна, поэтому приплетать требования для обоснования конкретной реализации по моим понятиям некорректно

Разработчики и определяли. Если перед Вами задача постоянно (99% случаев) искать версию сложного (т.е. представленного несколькими таблицами) объекта, действовавшую на момент времени, то желание городить еще и отдельные исторические таблицы пропадает напрочь.

Здравствуйте, C0s, Вы писали:

C0s>а для эффективных вычислений продумывать дополнительные структуры данных, т.е. отделять их от данных для поддержания операций. тогда можно было бы реализовывать событийные (или квазисобытийные) подходы обработки данных и, как следствие, выделение биллинга как модуля из операционной части (вплоть до использования отдельной БД)


Так CBOSS — это в основном тот самый выделенный биллинг и есть. Представлен "дополнительными структурами данных, предназначенных для эффективных вычислений"
А операционная часть... Как бы Вам сказать, на фоне "вычислительной" она невелика и ничуть не хуже работает на "версионных" таблицах.
Объем кода, кстати, существенно меньше.
Объем данных по отношению к Вашему предложению меньше в два раза.
Расходы на поддержку этих данных — в несколько раз.


C0s>

PNC>> (select * from emp 
PNC>>  UNION ALL
PNC>>  select * from emp_hist)
C0s>

А теперь представьте, что эту радость надо расписывать для запроса к 5-10 таблцам?

Здравствуйте, C0s, Вы писали:

C0s>из employee_hist должна идти ссылка на department(id), мне вообще странно представить, что история изменения атрибутов департамента имеет какое-то отношение к сотруднику.
C0s>при этом я не вижу, какие срезы данных нам становятся недоступными. или я что-то проглядел?

Да, проглядели — предлагаемое вами решение не соответствует описанным выше

Автор: PNCHL
Дата: 16.01.06

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

Здравствуйте, C0s, Вы писали:

J>>Насчет "много" — это отдельный вопрос. А насчет "разных" — это бывает. Если каждый из 4 параметров может меняться независимо, но с вероятностью 0.01% за полгода — таблицу отдельную можно не создавать?
J>>Последняя запись из истории будет собираться из нескольких таблиц. Это раз. При смене сразу нескольких атрибутов может потребоваться запись в несколько исторических таблиц. Это два.

C0s>я не случайно написал про операцию изменения. чуть более сухим языком:

C0s>если имеем для изменения объектов типа A операцию updateObjectA(pk, a1, a2, a3, a4), то a1, a2, a3, a4 — это взаимосвязанные атрибуты. для меня это значит, что одной таблицы истории достаточно

C0s>если же имеем две операции для обновления объектов того же типа update1ObjectA(pk, a1, a2) и update2ObjectA(pk, a3, a4), то, скорее всего, a1,a2 я положу в одну таблицу историй, a3,a4 — в другую. при этом ситуацию, когда попросят добавить update3ObjectA(pk, a1, a3) буду рассматривать как недостаточно проработнные требования.

Ну, помимо существенного усложнения работы на этапе проектирования (определить, какме атрибуты с какими связаны, могут ли они изменяться независимо и т.п.), есть еще один нюанс. Если возможны изменения любого атрибута (к примеру, для информации о человеке: изменения адреса, телефона, фамилии, паспортных данных — вполне независимые операции), то таблицы у нас будут плодиться и размножаться.

C0s>а в целом, сам факт разделения a1,a2 от a3, a4 на уровне требований, для меня значит, что запросы соединяющие a1,a2,a3,a4 вместе будут маловероятными
C0s>то бишь, к примеру (более-менее абстрактному), если мне надо услугу, оказываемую абоненту на регулярной основе, и мне важен статус абонента на определенный момент времени, но вообще не волнует его адрес, то в историю статусов абонентов я полезу, а в историю его адресов — нет

В форме необходимы все данные, и если ты хочешь посмотреть абонента когда-то в прошлом, то придется лезть во все истории.

J>>Очень даже просто. Добавляется конструкция вида '<some_date> between from_date and to_date'. (Затем это очень неплохо можно секционировать по from_date.) При апдейте объекта апдейтится to_date старой версии и инсертится новая версия.

C0s>т.е. OR с двумя сравнениями по неиндексированным полям лучше, чем джойн по уникальному ключу? возможно....

AFAIK, between раскрывается через AND, и обычно существует ключ по <n, from_date, to_date>, где n — номер объекта.

C0s>>>что касается последующих выборок, то я не вижу большой разницы в selectе из одной таблицы и в selectе с джойном по части уникального ключа. понятно, что второе медленнее, но разговор-то не только об аспекте быстродействия в runtime, а о том, что у каждого подхода при оценке по разным направлениям обнаруживаются свои достоинства и недостатки.

J>>Возможно. Только при выборе атрибутов объекта на некоторый момент времени необходимо будет искать по дате в КАЖДОЙ исторической таблице и джойнить их друг с другом и с актуальной.

C0s>разные исторические таблицы друг с другом джойнить-то зачем? в общем случае это излишне, но возможно только для "двойственных" таблиц (т.е. тех, которые для одних бизнес-объектов как истории, но сами по себе также содержат бизнес-объекты)

Согласен, друг с другом не надо, но все равно, придется джойнить последовательно.

Здравствуйте, PNCHL, Вы писали:

PNC>Если под "событийностью" вы понимаете навешивание обработчиков на триггеры ........
PNC>Я, однако, считаю, что вместо использования триггеров лучше делать API — функции для выполнения основных операций над объектами и уже в эти функции встраивать вызовы обработчиков событий...

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

я имел в виду нечто другое: с точки зрения системы в целом желание включить услугу — это событие, приходящее от оператора системы (или через центр обработки sms-заявок, что не меняет картины). с точки зрения внтутреннго устройства системы обрабатывать это событие мы можем целиком синхронно или поэтапно. так или иначе оно поступает на вход в операционную часть, которая должна проверить, можно ли назначить услугу, не противоречит ли состояние абонента/контракта ее назначению, все ли в порядке с кредитным контролем абонента и в конце после изменения состояния абонента также добавить данные, которые впоследствии позволят при биллинге учесть факт наличия этой услуги.
под квазисобытийным подходом я понимаю ту архитектуру, которая могла бы быть реализована через события асинхронно (например, операционная часть посылает message о том, что у абонента X появляется услуга Y, которое биллинговый модуль у себя принимает и обрабатывает в своей транзакции, заполняя свои биллинговые структуры данных), но на деле реализована путем синхронного вызова из операционной части какого-то API биллингового модуля

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

Здравствуйте, Аноним, Вы писали:

А>Объем кода, кстати, существенно меньше.

меньше, чем где?

А>Объем данных по отношению к Вашему предложению меньше в два раза.

интересно посмотреть, как сформирована оценка. вроде ниоткуда не следует, что будет больше. номера версий — это o-малое от общего объема данных, а больше в моем варианте ничего не добавлялось

А>Расходы на поддержку этих данных — в несколько раз.

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

PNC>>> (select * from emp 
PNC>>>  UNION ALL
PNC>>>  select * from emp_hist)

А>А теперь представьте, что эту радость надо расписывать для запроса к 5-10 таблцам?

в моем варианте таких запросов бы не было, не понятно, какой мой пост дал основание думать об этом

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

Здравствуйте, PNCHL, Вы писали:

C0s>>из employee_hist должна идти ссылка на department(id), мне вообще странно представить, что история изменения атрибутов департамента имеет какое-то отношение к сотруднику.
C0s>>при этом я не вижу, какие срезы данных нам становятся недоступными. или я что-то проглядел?

PNC>Да, проглядели — предлагаемое вами решение не соответствует описанным выше

Автор: PNCHL
Дата: 16.01.06

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

физически можно навесить триггер, но я бы не стал, просто потому что физическое удаление для такого рода систем операция обычно редкая
да и вообще, как-то я больше беспокоился насчет selectов ("срезы данных"), а не deletов

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

не думаю, что так уж однозначно "исключает". например, удаление может быть логическим через флаг, а партиционирование сделать так, что все логически удаленные больше N дней назад оказываются в отдельном томе, который потом хоть в offline на полку. вполне, может что я и заблуждаюсь насчет возможностей партиционирования, но понимаю, что всегда можно запрограммировать API, которое аккуратно все удаляет из таблиц в нужном порядке в любом варианте

да и, слабо представляю, ваш-то вариант чем здесь лучше? любое удаление у вас должно привести к потере информации, а если были сотрудники, то как тогда очистка согласуется с требованиями не удалять?

Здравствуйте, Jester, Вы писали:

J>Ну, помимо существенного усложнения работы на этапе проектирования (определить, какме атрибуты с какими связаны, могут ли они изменяться независимо и т.п.), есть еще один нюанс. Если возможны изменения любого атрибута (к примеру, для информации о человеке: изменения адреса, телефона, фамилии, паспортных данных — вполне независимые операции), то таблицы у нас будут плодиться и размножаться.

с моей точки зрения любая анаграфическая информация суть связанная, у меня бы для нее была бы одна таблица

J>В форме необходимы все данные, и если ты хочешь посмотреть абонента когда-то в прошлом, то придется лезть во все истории.

по абоненту обычно столько данных, что слабо верится, что они в одну форму умещаются. а обращение к каждой отдельной закладке (модальному окну по кнопке "детали того-то" или "детали сего-то" — не суть важно) при грамотном подходе к организации GUI много соединений не потребует. ну не могу я себе представить, что в одной и той же таблице потребуется как статус абонента так и номер его паспорта на тот момент. это же биллинг, а не мвд

J>AFAIK, between раскрывается через AND, и обычно существует ключ по <n, from_date, to_date>, где n — номер объекта.

ага, AND, согласен , но не суть важно...

J>>>Возможно. Только при выборе атрибутов объекта на некоторый момент времени необходимо будет искать по дате в КАЖДОЙ исторической таблице и джойнить их друг с другом и с актуальной.

ну я уже говорил, что ИМХО вероятность одновременного присоединения всех историй мне кажется малореальной

J>Согласен, друг с другом не надо, но все равно, придется джойнить последовательно.

или параллельно. сервер БД, наверное, умеет распараллеливать? а в случае чего ему, наверное, можно и помочь путем разнесения данных для возможности параллельного считывания?

Здравствуйте, C0s, Вы писали:

C0s>физически можно навесить триггер, но я бы не стал, просто потому что физическое удаление для такого рода систем операция обычно редкая
C0s>да и вообще, как-то я больше беспокоился насчет selectов ("срезы данных"), а не deletов

Речь вообще-то шла о ссылочной целостности и о том, почему в CBOSS нет ключей. Для selectов FK не нужен.

C0s>да и, слабо представляю, ваш-то вариант чем здесь лучше? любое удаление у вас должно привести к потере информации, а если были сотрудники, то как тогда очистка согласуется с требованиями не удалять?

Опять же, речь шла о вариантах использования FK для обеспечения ссылочной целостности исторических данных. Хорошего варианта пока никто не предложил...

Здравствуйте, C0s, Вы писали:

C0s>Здравствуйте, Аноним, Вы писали:

А>>Объем кода, кстати, существенно меньше.
C0s>меньше, чем где?
Меньше, чем в варианте с выделенными "данными для эффективных вычислений" на отдельном сервере.
Просто потому, что реализовать поддержку как "правильной" схемы, так и "эффективной" в том или ином виде придется

А>>Объем данных по отношению к Вашему предложению меньше в два раза.
C0s>интересно посмотреть, как сформирована оценка. вроде ниоткуда не следует, что будет больше. номера версий — это o-малое от общего объема данных, а больше в моем варианте ничего не добавлялось

Ну как же — оригиналы + "выделенный сервер"

А>>А теперь представьте, что эту радость надо расписывать для запроса к 5-10 таблцам?
C0s>в моем варианте таких запросов бы не было, не понятно, какой мой пост дал основание думать об этом
Был бы другой вариант, еще хуже — поймите, "исторические" данные нужны не "иногда". Они нужны практически всегда

C0s>если же говорить о коде для работы с историческими таблицами, то на стороне ООЯ это не программируется копи-пастом, а делается реюзом кода через делегирование. разговор про программирование вычислений, впрочем, для этой ветки как-бы оффтопик
Зато не оффтопик следующее: есть данные, которые следует организовать наиболее эффективным образом.
Что есть мерило эффективности? ИМХО — решаемые задачи.
"реюз кода через делегирование" — звучит, безусловно, красиво, но ни коим образом не отвечает на вопрос "как эффективно организовать данные" для решения основной задачи биллинговой системы — оценки трафика и выставления счетов.

В этой ветке много раз звучала мысль что МТС "воровал деньги" ввиду неконсистентности данных, которая ворзникла ввиду отсутствия PK/FK. Это неправда.
Механизмы возникновения таких слухов известны и описаны. И первый из них — online отражение на балансе абон. платы в "посекундной" пропорции с начала месяца.
Предложенные решения с разделением данных на оперативные и исторические с единственной целью введения PK/FK:
— Снижают эффективность решения основной задачи
— Повышают стоимость сопровождения системы
— Существенно усложняют либо делают невозможным проведение операций "задним числом"
— Ни коим образом не в состоянии повлиять на возникновение слухов класса "оператор ворует деньги"
Так для чего? Ради искусства? CBOSS — система вполне себе прикладная.

Я без подписи, но все таки
ЗЫ: Когда я пришел в CBOSS, я тоже был полон подобных идей.
Но практические эксперименты (с замерами) убедили меня, что существующая практика для решения поставленных задач подходит все-таки лучше высоконаучных (и даже в чем-то даже правильных) концепций "ограничения целостности обязаны быть реализованы штатными средствами СУБД". Я намеренно опустил "любой ценой". Поскольку цена оказывается выше ожидаемой

Здравствуйте, Аноним, Вы писали:

А>ЗЫ: Когда я пришел в CBOSS, я тоже был полон подобных идей.
А>Но практические эксперименты (с замерами) убедили меня, что существующая практика для решения поставленных задач подходит все-таки лучше высоконаучных (и даже в чем-то даже правильных) концепций "ограничения целостности обязаны быть реализованы штатными средствами СУБД". Я намеренно опустил "любой ценой". Поскольку цена оказывается выше ожидаемой

Этот спор бесконечен. У вас всегда будут оппоненты, которые будут упорно доказывать, что существует элегантное решение с применением PK/FK и что именно это решение и является единственно правильным. На RSDN публика еще более или менее терпима. Поднимись такой вопрос на SQL.RU, вы бы устали отписываться от наездов "крутых знатоков", которые прочитали толстые книжки и уверовали в написанное всеми фибрами своей души. На деле же людей, которые действительно имеют реальный опыт создания и (что немаловажно) длительного сопровождения и доработки систем такого уровня сложности как CBOSS, на этих форумах единицы. А уж тем более, если речь идет о таких материях как управление сложностью и затратами на сопровождение — ведь подавляющее большинство наших доморощенных систем не живут более 2-4 лет.

PS: Единственное, что можно заметить в отношении CBOSS с учетом результатов данного обсуждения — это то, что в свое время выбор именно ORACLE в качестве базовой СУБД для этой системы возможно и не был так уж оправдан. Тут по требуемым характеристикам даже лучше смотрелись бы объектные СУБД а-ля Versant, ObjectStore ... Хотя понятно, что в те годы, когда создавалась архитектура системы CBOSS (да и сегодня тоже) найти в России специалистов по нереляционным системам практически невозможно. У нас вообще какой-то вывих в головах архитекторов в данном вопросе — ORACLE пытаются втиснуть везде — и к месту, и не к месту. Впрочем, это уже оффтоп ...

Здравствуйте, PNCHL, Вы писали:

PNC>Здравствуйте, C0s, Вы писали:

Разберем как бы конкретно я, поступил в таком конкретном случае. Может в вашем случае нужно по другому. Но ИМХО, что все несдотатки либо устраняются, либо в данном конкретном случае являются даже достоинствами.

table emploee(emp_id(PK), sex, date_of_birth, resume_date, date_fin)
table emplpoee_hist(emp_emp_id (FK), start_date, end_date, ...)
table department(dep_id(PK), name, date_fin)
table department_hist(depHist_id (PK),dep_dep_id(FK), start_date, end_date, ...)

Истории друг на друга не ссылаются.

Плюсы
1. Нельзя удалить подразделение, если в нем, кто-то когда-то работал. YES. Дополнительная защита от дурака.
2. Нельзя удалить подразделение, если у него есть хоть, какая-нибудь история. YES.
3. Нельзя удалить сотрудника, если есть хоть какая-ниюудь история. YES.
4. Нельзя что-то вносить задним числом. YES. Знаете сколько проблем возникает из-за таких внесений!

Возможные проблемы.
1. Проблема в возможности удаления истории. С ходу не приходит способов гарантирующих невозможность удаления истории.
2. Проблема с большими запросами. Ну в общем и целом это погоды во многих случаях не делает. Почему можно порассуждать отдельно, но не примере из 4 таблиц, поскольку это не смещно.

Минус
1. С ваших слов начинаются проблемы со скоростью работы с историей.

Зачем date_fin? Так вот date_fin, для отображения пользователю и запрета работы изменять какие-либо его данные вообще. Назначать сотрудников и т.д.

Можно еще несколько навороченный вариант для защиты.

table emplpoee_addhist(emp_emp_id (FK), start_date, date_fin)
table department_addhist(depHist_id (PK),dep_dep_id(FK), date_fin)

Остальное в прежней силе.

Если похимичить с данным подходом. При довольно неплохой переносимости для разных БД можно довольно хорошую защиту от дурака сделать. Хотя от м..... все равно не спасет. Поскольку он и триггеры отключит и PK/FK удалит. Только в данном случае он уже занимается модификацией структуры базы данных, а за это уже пора бить по рукам. То есть строчка в договоре, о том что разработчик не отвечает за правильную работу программы в случае ручного модифицирования структуры базы данных ОБЯЗАНА быть ИМХО. Так что сумму можно будет запросить приличную, чтобы отбить желание это делать.

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

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