Одна таблица или две?

SAV · Сообщение **SAV** » 28 авг 2006, 12:46

Задача решаемая, но хотелосьбы узнать какая реализация будет грамотнее.
задача: Хронология (история/лог) событий объектов.
Вариант 1:Одна таблица с кучей полей на один объект - разные пользователи выполняют некие действия, их результаты пишутся в разные поля таблицы(в зависимости от действия), при этом поля от других действий в этой записи остаются NULL. Как в этом варианте собрать все последние результаты действий????
Вариант 2:Несколько таблиц связанных по времени при этом каждая таблица является логом только для определённого вида действий.В этом варианте результаты всех последних действий это select first 1 ... order by ВРЕМЯ.

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

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

Dimitry Sibiryakov

Я бы сделал одну таблицу с тремя полями: объект, дата, действие. Все.

WildSery · Сообщение **WildSery** » 28 авг 2006, 13:00

Собственно, ему потребуется и справочник событий.
Но для собственно истории/лога практически всегда применяется одна таблица.

Merlin · Сообщение **Merlin** » 28 авг 2006, 13:15

SAV писал(а):Задача решаемая, но хотелосьбы узнать какая реализация будет грамотнее.
задача: Хронология (история/лог) событий объектов.
Вариант 1:Одна таблица с кучей полей на один объект - разные пользователи выполняют некие действия, их результаты пишутся в разные поля таблицы(в зависимости от действия), при этом поля от других действий в этой записи остаются NULL. Как в этом варианте собрать все последние результаты действий????

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

SAV писал(а): Вариант 2:Несколько таблиц связанных по времени при этом каждая таблица является логом только для определённого вида действий.В этом варианте результаты всех последних действий это select first 1 ... order by ВРЕМЯ.

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

SAV писал(а):
("вроде" поскипано дабы не разводить флейм)

пользователь может создавать сам действия с определённым набором входных ивыходных полей.

Тут вот что-то сомнения насчёт консерватории одолевают... Но, даже если это действительно так, то тем более нужен справочник действий.

SAV · Сообщение **SAV** » 28 авг 2006, 14:15

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

Ближе к д(т)елу:
Вот, например, таблица-лог с которой юзеры работают:

Код: Выделить всё

create table OBJECT_... /* например OBJECT_12 генерируется при создании объекта*/  
(
   ДАТА TIMESTAMP NOT NULL default CURENT_DATETIME PRIMARY KEY,
   ИМЯ_ПОЛЬЗОВАТЕЛЯ VARCHAR(100) default CURRENT_USERNAME
   ИМЯ_ДЕЙСТВИЯ VARCHAR(100) NOT NULL
  ВХОД.ДАННЫЕ№1 для действия№1     INTEGER,
  ВХОД.ДАННЫЕ№2 для действия№1     INTEGER,
  ВХОД.ДАННЫЕ№1 для действия№2     INTEGER,
);

Справочник действий есть, с типами входных и выходных параматров действия и тд. Пользователь выбирает объект->выбирает действие(генерируется диалог ввода на основании входных полей)->вводит данные->жмёт кнопку "выполнить действие".

Выполняет действие №1 генерируется INSERT вставляются поля для действия №1 , а ВХОД.ДАННЫЕ№1 для действия№2 будет NULL. Не может же один пользователь в одно время выполнить несколько действий, следовательно и заполнит только поля связанные с этим действием..
В итоге получаем лог работы с объектом.Но как получить статус? то есть данные всех событий в одной "строке"?

Merlin писал(а): Затрахаешься потом писать ветвистые запросы или формировать их динамически, с обращениями к разным таблицам в зависимости от типа действия.

С этим я согласен! Поэтому второй вариант надо исключать!

И... прошу прощения за ошибку в топике, данные ВХОДНЫЕ, так как выполнив над ними действие ..Х.. можно получить результат действия ..Х..

Сообщение **kdv** » 28 авг 2006, 14:47

ИМЯ_ДЕЙСТВИЯ VARCHAR(100) NOT NULL

ё-моё... должен быть СПРАВОЧНИК действий.

ВХОД.ДАННЫЕ№1 для действия№1 INTEGER,
ВХОД.ДАННЫЕ№2 для действия№1 INTEGER,
ВХОД.ДАННЫЕ№1 для действия№2 INTEGER,

это вообще ни в какие ворота.

В итоге получаем лог работы с объектом.Но как получить статус? то есть данные всех событий в одной "строке"?

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

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

все сделано на процедурах. Создание - добавляется запись, вызывается обработчик. Обработчик ищет условия, по условиям применяет действия.
Частично это описано тут:
www.ibase.ru/devinfo/treedb2.htm
Там пример списка действий, одновременно являющийся списком флагов прав.

Merlin · Сообщение **Merlin** » 28 авг 2006, 14:47

Во первых, не делай вот так

Код: Выделить всё

 ДАТА TIMESTAMP NOT NULL default CURENT_DATETIME PRIMARY KEY,

а то будет больно. Проверено электроникой. Время - оно дискретно и дискрет не так уж мал, очень быстро пойдут нарушения ПК при записи лога. Этот таймштап должен быть атрибутом лога, а ПК - обычный искусственный на генераторе. Во-вторых, добавь и в объект тоже, не только в лог, поле 'тип действия', повесь логирование на триггера объекта и пиши в них в лог тупо все поля как есть. Тогда в объекте будет, кроме всего прочего, инфа о последнем действии, а в логе - состояния объекта целиком и ссылки на действие, которое объект в это состояние привело. Или у тебя апдейтов-делетов объектов нет, только инсёрты?

Сообщение **kdv** » 28 авг 2006, 14:55

посмотрел у себя - в таблице HISTORY ПК не искуственный - документ, действие, группа, пользователь, состояние и тип документа. Почти половина атрибутов. Дата события в ПК не входит

ой, вру. входит

Merlin · Сообщение **Merlin** » 28 авг 2006, 15:20

kdv писал(а):посмотрел у себя - в таблице HISTORY ПК не искуственный - документ, действие, группа, пользователь, состояние и тип документа. Почти половина атрибутов. Дата события в ПК не входит

Имхо в логе ПК служит исключительно для фиксации последовательности событий, по причине невозможности использовать для этого таймштамп. Естественный композит там по-моему нафиг не упал, только оптимизатору голову морочить. Под типовые запросы анализа лога индексы надо на нём лепить, а они будут явно короче и разнообразнее по следованию сегментов, а может и вообще односегментные. Если вообще надо. Я примерно года три назад естественным композитам вообще тотальную войну объявил - затрахался джойнить по 11 полям таблицы

Необходимая уникальность на индексах или Unique, а ПК-ФК - искусственные. Даже рискуя местами RI - в приложении и триггерах-процедурах ключи деталей всё равно формируются в большинстве случаев автоматически, а не ручками.

kdv писал(а): ой, вру. входит

это тебя наличие пользователя в ПК спасает от неприятностей. И то - если в один и тот же лог пишется от одного и того же пользователя-действия разными триггерами... А хотя бы и одним. Я в первый раз на это наступил на логе себестоимости по ценовым группам. У меня туда пишется при регистрации состава производственного заказа, счёта, поступления (транспортной партии), прохождения ею таможни, складских операций, всё потоварно, ессно, но в записи, характеризующие товарную группу. Ну и при редактировании рукоблудных полей собственно группы и при переносе товаров из группы в группу. Вот, скажем, приводится в активное состояние счёт о позициях так 60 и пошла стрельба в цикле по составу в ценовые группы, а от них в архив. Ну и два соседних товара в составе счёта в одной группе. Обломы на четвёртый день эксплуатации пошли, на пяти тогда ещё регистраторах в этих подсистемах.

Сообщение **kdv** » 28 авг 2006, 15:56

Естественный композит там по-моему нафиг не упал, только оптимизатору голову морочить.

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

SAV · Сообщение **SAV** » 28 авг 2006, 17:28

kdv писал(а):"долбление" одним пользователем одних и тех же действий чаще раза в секунду было бы похоже на флуд.
Насчет естественных композитов - согласен.

Присоединяюсь.

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

Сообщение **kdv** » 28 авг 2006, 17:30

см. также топик
http://forum.ibase.ru/phpBB2/viewtopic. ... highlight=

SAV · Сообщение **SAV** » 28 авг 2006, 17:57

kdv писал(а):см. также топик
http://forum.ibase.ru/phpBB2/viewtopic. ... highlight=

ну вот и отвалилась проблема с ПК, буду использовать дату качестве пк, в моём случае пользовотели не так активны чтоб выполнять дествия раз в милисекунду.

Merlin · Сообщение **Merlin** » 28 авг 2006, 17:59

Ндя. Мерфи икнулось основательно

SAV · Сообщение **SAV** » 28 авг 2006, 18:39

Merlin писал(а):Ндя. Мерфи икнулось основательно

Дело не в Мерфи

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

Merlin · Сообщение **Merlin** » 28 авг 2006, 19:03

Ну, чем тебе и кого валить, это ты сам выбирай, но, прочитавши, что таймштамп на клиенте и сервере в принципе не может быть одинаковым, прийти к выводу, что поэтому его следует использовать в качестве ПК - это сильно

Если что-то может быть истолковано неправильно, то только так оно и будет истолковано. Если не может быть истолковано неправильно - то тоже будет именно неправильно и истолковано (С)

SAV · Сообщение **SAV** » 28 авг 2006, 19:47

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

Ivan_Pisarevsky

буду использовать дату качестве пк

Мыши кололись, давились, но продожали жевать кактус...

В фб есть стандартный механизм для формирования ключей называется "GENERATOR"!!!

Ну почему каждый новичек норовит изобресь свой лисапет?

WildSery · Сообщение **WildSery** » 29 авг 2006, 10:42

Ivan_Pisarevsky писал(а):Ну почему каждый новичек норовит изобресь свой лисапет?

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

CyberMax · Сообщение **CyberMax** » 29 авг 2006, 12:20

Поддержу Merlin'а. Почти с самого начала работы с БД тоже полностью отказался от естественных ключей для ПК и ВК. И серверу проще интеджеры пережевывать, и база наглядней и прочая... В книжках по БД теорию пишут, которая, как известно, от практики отличается.

iBase.ru Forum

Одна таблица или две?

Одна таблица или две?

Re: Одна таблица или две?

Re: Одна таблица или две?