Re[9]: CBOSS - если кто может, объясните почему нет ключей? - Базы данных

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

А>Причин ровно две:
А>1) Для большинства таблиц CBOSS PK создавать бессмысленно, поскольку обному объекту соответствуют несколько записей-версий, различаемых по датам начала/завершения действия. По этой же причине нельзя создать FK, поскольку он ничего не сможет проконтролировать (даты версий родительского дочернего объектов, вообще говоря, не связаны).

так а почему версионность объектов не выделили в отдельные вспомогательные таблицы? или это типа так модно у самых лучших в России программистов oracle?

А>2) Первой причины вообще-то достаточно

т.е. такое архитектурное решение кривой версионности сделали специально для того, чтобы обосновать отсутствие констрейнтов?

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

A>Попробую еще тут поумничать...

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

A>С этим не поспоришь. Но скажите, сколь часто в CBOSS происходит операция удаления? На самом деле, я подозреваю, что ж0сткие вставки идут только в таблицы звонков, и всё. Всё остальное делается гораздо реже и гораздо более вручную. ТАк что, боюсь, 10% это ооочень большое преувеличение.

Хм. На самом деле, операция удаления в CBOSS не является системной. Это обусловлено объектной моделью данных в CBOSS'е. Так что и в самом деле, серьезность проблемы в данном месте преувеличена. Более того, в CBOSS'е ЕСТЬ таблицы, связанные по PK/FK — к примеру, в функционале ЕСПП, но там объектная модель CBOSS не применяется

.

A>>>Кроме того, из-за прикольной системы именования столбцов, довольно трудно вникнуть в устройство базы.

PNC>>Все столбцы в таблицах именуются согласно CBOSS-овским стандартам. Они, как раз помогают вникнуть в устройство базы. Хотя, конечно, разобраться непросто — таблиц порядка 3000...

A>воот эти стандарты мне и не очень хорошими показались. Коненчо, не отвратительными

Но .. видите ли, очень ТРУДНО понять. на ЧТО идет ЛОГИЧЕСКАЯ (воображаемая на уровне приложения) ссылка по полю UP с названием UP.

А это нужно конечному пользователю? Или Вы намерены заместить CBOSS в части написания приложений для данной модели данных?

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

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

А>>Причин ровно две:
А>>1) Для большинства таблиц CBOSS PK создавать бессмысленно, поскольку обному объекту соответствуют несколько записей-версий, различаемых по датам начала/завершения действия. По этой же причине нельзя создать FK, поскольку он ничего не сможет проконтролировать (даты версий родительского дочернего объектов, вообще говоря, не связаны).

C0s>так а почему версионность объектов не выделили в отдельные вспомогательные таблицы? или это типа так модно у самых лучших в России программистов oracle?

То есть создавать на каждый объект модели данных по две таблицы с одинаковой структурой?

А>>2) Первой причины вообще-то достаточно

C0s>т.е. такое архитектурное решение кривой версионности сделали специально для того, чтобы обосновать отсутствие констрейнтов?

Скорее отсутствие констрейнтов проистекает из версионности. Логически.

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

C0s>>так а почему версионность объектов не выделили в отдельные вспомогательные таблицы? или это типа так модно у самых лучших в России программистов oracle?

J>То есть создавать на каждый объект модели данных по две таблицы с одинаковой структурой?

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

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

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

А>>>2) Первой причины вообще-то достаточно

C0s>>т.е. такое архитектурное решение кривой версионности сделали специально для того, чтобы обосновать отсутствие констрейнтов?

J>Скорее отсутствие констрейнтов проистекает из версионности. Логически.

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

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


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

в этом случае для получения актуальных на момент времени t данных достаточно наложить на это объединение одно условие


 select *
 from (select * from emp 
       UNION ALL
       select * from emp_hist) all_emp_data
 where t between all_emp_data.begin_date and all_emp_data.end_date

Как легко видеть, в этом случае выгоднее иметь одну таблицу содержащую и историю и актаульные данные.

Часто говорят, что выделять актуальные данные в отдельную таблицу выгодно, поскольку они используются гораздо активнее, чем исторические. Однако даже в этом случае это необязательно — достаточно выделить специальную секцию (partition) в таблице в которую будут попадать только актуальные данные.

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

.
Поправьте, плз, если способ, на самом деле, есть...

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

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

C0s>>>так а почему версионность объектов не выделили в отдельные вспомогательные таблицы? или это типа так модно у самых лучших в России программистов oracle?

J>>То есть создавать на каждый объект модели данных по две таблицы с одинаковой структурой?

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

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

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

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

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

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

J>>Скорее отсутствие констрейнтов проистекает из версионности. Логически.

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

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

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

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

A>>воот эти стандарты мне и не очень хорошими показались. Коненчо, не отвратительными

Но .. видите ли, очень ТРУДНО понять. на ЧТО идет ЛОГИЧЕСКАЯ (воображаемая на уровне приложения) ссылка по полю UP с названием UP.

J>А это нужно конечному пользователю? Или Вы намерены заместить CBOSS в части написания приложений для данной модели данных?

А почему нет?

На семом деле все немного не так...
Но при необъодимости произвести какие-то рассчеты, соорудить отчет, пусть даже создать малеьнкую утилитку, которая не предусмотрена CBOSS,
было бы мило иметь грамотно обозванные данные.
Кроме того, работай я в CBOSS, тоже было бы приятнее

Как ни крути, везде приятнее!

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

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

A>>>воот эти стандарты мне и не очень хорошими показались. Коненчо, не отвратительными

Но .. видите ли, очень ТРУДНО понять. на ЧТО идет ЛОГИЧЕСКАЯ (воображаемая на уровне приложения) ссылка по полю UP с названием UP.

J>>А это нужно конечному пользователю? Или Вы намерены заместить CBOSS в части написания приложений для данной модели данных?

A>А почему нет?

Потому что money

A>На семом деле все немного не так...
A>Но при необъодимости произвести какие-то рассчеты, соорудить отчет, пусть даже создать малеьнкую утилитку, которая не предусмотрена CBOSS,
A>было бы мило иметь грамотно обозванные данные.

Для решения этой проблемы можно напрячь техподдержку.

A>Кроме того, работай я в CBOSS, тоже было бы приятнее

А если бы работал в CBOSS, вообще бы проблем не было: запускаешь маленький скриптик и смотришь описания полей

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

PNC>>Oracle так не делает. Я даже специально проверил — план запроса вообще не меняется. Видимо в MS SQL помимо парсинга и генерации плана запроса оптимизатор занимается еще и семантическим анализом...
GZ>Семантическая оптимизация(так они называются) у Oracle также имеется. Ну например, примерный запрос:
GZ>

GZ>select A1.* from A1, A2 where A1.ID=A2.ID AND A2.ID>50
GZ>

GZ>если а1 существенно меньше a2 то фильтрация(в большинстве случаев) будет по меньшему a1.

Это не совсем семантический анализ — Oracle не анализирует смысл данных и наложенные на них ограничения.
Пример, если у нас создана таблица с ограничением на столбец not null:

  create table t1(id number not null)

то для того, чтобы выяснить сколько в таблице записей с ПУСТЫМ ID

  select count(*)
  from t1
  where id is null

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

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

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

select * from t1 where id<100 and id>1000

Ессно, при разборе такое в любом случае обойти он не сможет. Хотя бы статистику ему для построения планов по 100>x>1000 нужно построить. И вполне понятно, что в таком случае запрос изначально пустой и бесцельный, но эту ситуацию он не обрабатывает.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

PNC>Поправьте, плз, если способ, на самом деле, есть...

Размножать можно очень ограниченный набор данных. Напримр, иметь табличку с ID и... и... ну пусть дата регистрации приложения, самая первая.
И одну историческую, с FK на этот ID

Уважаемый PNCHLЮ видите ли, все ваши уверения о том, что невозможно создать целостную базу с историчностью, они неверны хотя бы потому, что я видел такую базу

Никаких торомзов, связанных с этим, не наблюдалось. Тормоза были связаны с другими вещами в других местах

Кстати, почему CBOSS, с такими прекрасными принципами, НЕ ОБЕСПЕЧИВАЕТ историчность аккумуляторов?

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

A>>>>воот эти стандарты мне и не очень хорошими показались. Коненчо, не отвратительными

Но .. видите ли, очень ТРУДНО понять. на ЧТО идет ЛОГИЧЕСКАЯ (воображаемая на уровне приложения) ссылка по полю UP с названием UP.

J>>>А это нужно конечному пользователю? Или Вы намерены заместить CBOSS в части написания приложений для данной модели данных?

A>>А почему нет?

J>Потому что money

Да да, увы. Вот таланты и пропадают в провинции

A>>На семом деле все немного не так...
A>>Но при необъодимости произвести какие-то рассчеты, соорудить отчет, пусть даже создать малеьнкую утилитку, которая не предусмотрена CBOSS,
A>>было бы мило иметь грамотно обозванные данные.

J>Для решения этой проблемы можно напрячь техподдержку.
Долго и нудно

A>>Кроме того, работай я в CBOSS, тоже было бы приятнее

J>А если бы работал в CBOSS, вообще бы проблем не было: запускаешь маленький скриптик и смотришь описания полей

Но я там у счастью или к сожалению — не работаю

PNC>>P.S. Кстати, вопрос апологетам внешних ключей: а как вообще с их помощью можно добиться ссылочной целостности для исторических данных? По-моему, без размножения данных в таблицах — никак. Ну а коли так, то и "радость от их использования" будет неполной

.
PNC>>Поправьте, плз, если способ, на самом деле, есть...

A>Размножать можно очень ограниченный набор данных. Напримр, иметь табличку с ID и... и... ну пусть дата регистрации приложения, самая первая.
A>И одну историческую, с FK на этот ID

Не совсем понял вашу идею. Объясните, плз, на каком-нибудь простом примере, как с помощью FK обеспечить ссылочною целостность, скажем, для двух объектов — "сотрудник" и "подразделение", если о каждом из них хранятся актуальные и исторические данные. При этом необходимо добиться выполнения следующих требований:
1) Данные о подразделении, актуальные на какой-либо момент времени, не могут быть удалены, если в этот момент времени в подразделении были какие-нибудь сотрудники;
2) Сотрудник не может быть привязан "задним числом" к подразделению, для которого не существует актуальной информации на тот момент времени;

A>Уважаемый PNCHL видите ли, все ваши уверения о том, что невозможно создать целостную базу с историчностью, они неверны хотя бы потому, что я видел такую базу

Поделитесь, плз, рассказом о том, что вы видели.

A>Кстати, почему CBOSS, с такими прекрасными принципами, НЕ ОБЕСПЕЧИВАЕТ историчность аккумуляторов?

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

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

PNC>Не совсем понял вашу идею. Объясните, плз, на каком-нибудь простом примере, как с помощью FK обеспечить ссылочною целостность, скажем, для двух объектов — "сотрудник" и "подразделение", если о каждом из них хранятся актуальные и исторические данные. При этом необходимо добиться выполнения следующих требований:
PNC>1) Данные о подразделении, актуальные на какой-либо момент времени, не могут быть удалены, если в этот момент времени в подразделении были какие-нибудь сотрудники;
PNC>2) Сотрудник не может быть привязан "задним числом" к подразделению, для которого не существует актуальной информации на тот момент времени;

Уже полночь, и мне трудно сосредоточиться

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


table emploee(emp_id(PK), sex, date_of_birth, resume_date)
table department(dep_id(PK), name)
table department_hist(depHist_id (PK),dep_dep_id(FK), number_history,start_date, end_date, director_wife_maden_name,...)
table emplpoee_hist(emp_emp_id (FK), number_history, start_date, end_date, depHist_depHist_id(FK), name, passport, salary...)

Ну для особо кривых рук
uunique index on emplpoee (emp_emp_id, number_history) (number_history это порядковый номер, в соответствии с датами. Можно генерить триггером или на уровне приложения, ка Вам нравится:))
uunique index on department_hist(depHist_id, number_history)

A>>Уважаемый PNCHL видите ли, все ваши уверения о том, что невозможно создать целостную базу с историчностью, они неверны хотя бы потому, что я видел такую базу

PNC>Поделитесь, плз, рассказом о том, что вы видели.
Это, наврное, коммерческая тайна ваших конкурентов

Так что, уверен, в вашей компании об этом знают не хуже меня

Если нет — то не мне восполнять этот ПРОБЕЛ

A>>Кстати, почему CBOSS, с такими прекрасными принципами, НЕ ОБЕСПЕЧИВАЕТ историчность аккумуляторов?

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

Ну это да.

Да, это был я

Чето браузер не всегда вспоминает, что я должен быть войденным в форум

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

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

C0s>>>так а почему версионность объектов не выделили в отдельные вспомогательные таблицы? или это типа так модно у самых лучших в России программистов oracle?

J>>То есть создавать на каждый объект модели данных по две таблицы с одинаковой структурой?

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

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

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

А>>>>2) Первой причины вообще-то достаточно

C0s>>>т.е. такое архитектурное решение кривой версионности сделали специально для того, чтобы обосновать отсутствие констрейнтов?

J>>Скорее отсутствие констрейнтов проистекает из версионности. Логически.

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

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

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

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

_>>Единсвтенный реалтайм биллинг — это у билайн. Там отрубить телефон могут прямо во время разговора, если деньги кончаются в процессе... У остальных идет постобработка после звонка.
A>Неправда, есть еще у МТС такое дело. Не на всех тарифах и не совсем везде, правда. Но повторюсь: ИМЕЕТСЯ.

только позавчера отрубили. MTC Москва Jeans 007
Причём на счету еще оставался цент или два, т.е. вообще говоря у меня несколько секунд еще оставалось (минута с Мегафоном обходиться теперь в 39 центов — выживают, сволочи, с обжитых тарифов)

Здравствуйте, PNCHL, Вы писали:
Маленькая просьба к разработчикам CBOSS: не мог бы ты попросить того, кто делал экспорт отчетов в HTML поправить таблички? А то там незакрытые теги, и импорт в Excel съезжает. Пример при необходимости могу предоставить.
Мелочь, а противно. Из-за этого трудно делать анализ своего трафика, даже если оператор предоставляет логи в цифровом виде.

1.1.4 stable rev. 510

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

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

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

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

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

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

	От:	C0s
	Дата:	15.01.06 23:33
	Оценка:

	От:	Jester
	Дата:	16.01.06 06:33
	Оценка:

	От:	Jester
	Дата:	16.01.06 06:37
	Оценка:

	От:	C0s
	Дата:	16.01.06 09:33
	Оценка:

	От:	PNCHL
	Дата:	16.01.06 09:36
	Оценка:	1 (1)

От:	Sinclair	https://github.com/evilguest/
Дата:	17.01.06 07:19
Оценка: