Re: PostgreSQL vs ...

From

Vladimir Pavlikov (2:5020/400)

To

Alexander Goldun (2:5054/37.63)

Date

2005-01-27T05:19:56Z

Area

SU.DBMS

From: "Vladimir Pavlikov" <vvp@soil.msu.ru>

Hello, Alexander!
You wrote to Vladimir Pavlikov on Wed, 26 Jan 2005 22:43:09 +0300:

AG> Рассмотрим простой пример. Авансовый отчет. Является документом.
...
AG> Документ один? Однозначно один.

Факт.

AG>  Если забыть про компьютеры, то это ОДНА бумажка, которая гуляет между
AG> отделами по определенному пути, в каждом отделе используется и
AG> заполняется информация на этой бумажке.

Факт.

AG> Теперь вспомним про компьютеры.
AG> Задачи разные? Разные (хотя тут нужно договориться о толковании термина
AG> "задача в данном контексте"). По крайней мере разные рабочие места
AG> с разными функциями.

Это ключевой момент. Дело не в рабочих местах. Пока мы имели дело
с бумажкой - речь о прохождении единого документа, отчета, по разным
фазам своей "жизни". Ни о какой выборке, тем более - групповой обра-
ботке речь не идет. Т.е. таки да - единая сущность. И в ней, заметь
_нет_ графы "состояние"! Изменяемой по мере прохождения бюро-
кратического круговорота.
"Теперь вспомним про компьютеры". Новые технические возможности
позволяют ввести новые же задачи. В частности - задачу обслуживания
документооборота. Которому, как и подавляющему большинству других,
имеющихся в других задачах сущностей не хватает - нужны и свои,
специфические. Которые можно обеспечить двояко - либо совместить
с существующими, наградив их несвойственными атрибутами (в исход-
ной задаче ненужными _никогда_!), либо ввести их явно.

AG>>>  А если для разных задач актуальны разные _пересекающиеся_ наборы
AG>>> статусов?
??>> С учетом вышенаписанного - это невозможно.

AG> Подотчетнику в журнале можно видеть только свои отчеты, но нужно в
AG> любых статусах.
AG> Бухгалтеру умолчанию в журнале надо видеть сданные и утвержденные. Если
AG> же за подотчетника заполняет бухгалтер, то еще и черновики и все
AG> остальные, например чтобы можно было ответить на вопрос "Что с моим
AG> отчетом"? Ответственному лицу неинтересны статусы до проверки
AG> бухгалтерией. Какому-нибудь финансовому аналитику плевать на все кроме
AG> проведенных. Всем им важно видеть, в каком состоянии находятся сейчас
AG> отобранные авансовые отчеты.
AG> В разных статусах и у разных пользователей разные наборы полей доступны
AG> для редактирования.

Текст понятен, но никаких пересекающихся наборов я не вижу. Набор
один, ну а то, что выборки могут идти по более, чем одному значению -
очевидно. Как это порождает пересекающиеся наборы? и где они пере-
секаются? Для выборки используется интересующий поднабор, и только.
Короче, здесь я не понял. Разве что  - доступ по редактированию ни к
теме, ни к базе, ни вообще к DBMS отношения не имеет :)

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

AG> Где в моих рассуждениях изъян? Ты считаешь, что это было бы корректнее
AG> реализовывать в 12 таблицах (6 статусов)?

Для начала отмечу, что единую сущность ты реализовал двумя таблицами.
И не видишь в этом никакого криминала. Я, кстати, тоже. И мне непонятно
возникновение криминала при появлении третьей таблицы. С учетом же
того, что эта третья относится к другой задаче, документообороту... ну,
понятно.
Изъян? Если ты видишь _две_ сущности в двух (1+2 и плюс "моя" третья)
таблицах, но объединил их намеренно (для собственного удобства,
убедившись, что в рамках стоящих перед тобой задач это объединение
не имеет неприятных следствий) - изъяна не вижу. Хотя и допускаю,
что по мере серьезного развития "вширь" они могут появиться.
Не видишь? - тогда изъян в недостаточности анализа, а дальше - как
повезет :)
Кстати, из чистого любопытства - в какую именно таблицу ты поместил
этот атрибут? Я догадываюсь, что в шапку, просто тут появляется еще
одна тема, но ее  - не будем :)

И - как я считаю. Да, полагаю (не утверждаю! - ты лучше знаешь свою
задачу) что корректнее реализовать одну дополнительную таблицу.
Собственно, никакая она не дополнительная, а самая что ни на есть
из основных - но в другой, документооборотной задаче.
А не 12 - атрибут-то один, вне зависимости от количества допустимых
значений. И на 2 умножать не надо - обе твои "подтаблицы" наверняка
имеют единый PK, как две части одного экземпляра. В этой таблице
будет PK отчета, статус (из практических соображений я бы для
"законченных" отчетов запись в таблицу делать не стал) и... что еще?
Это - ключевой момент номер два. Да много чего можно придумать.
К примеру много позже захочется добавить поле "количество возвра-
тов на предыдущий этап обработки" для получения статистики
добросовестности обслуживания документов :) Это вполне уклады-
вается в атрибут одной из сущностей задачи документооборота, но -
считает ли кто-нибудь, что и такой атрибут можно "притянуть за
уши" к сущности "авансовый отчет"? А ведь их, таких, может
быть немало... И, возможно, одной таблицы не хватит :)

With best regards, Vladimir Pavlikov.  E-mail: vvp@soil.msu.ru



-- 
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
--- ifmail v.2.15dev5.3
 * Origin: Talk.Mail.Ru (2:5020/400)
SEEN-BY: 50/203 520 450/159 186 451/30 452/25 100 454/9 455/15 461/33 43 74
SEEN-BY: 461/106 132 640 463/92 464/34 465/213 469/125 999 478/44 550/5068
SEEN-BY: 4614/20 4616/3 4625/8 9 4627/10 4635/4 1024 4651/25 4653/10 4657/50
SEEN-BY: 5000/76 5000 5001/50 211 5001 5002/5002 5003/34 5006/1 5007/1 5009/14
SEEN-BY: 5010/53 70 146 5011/13 5012/23 5015/4 28 5019/5 22 5020/52 104 115
SEEN-BY: 5020/118 128 133 150 175 201 362 371 400 545 639 642 715 755 758 780
SEEN-BY: 5020/794 892 894 902 921 968 982 1057 1100 1169 1200 1212 1234 1523
SEEN-BY: 5020/1604 1626 1642 1826 1835 1873 1922 1930 1992 2020 2200 2238 4400
SEEN-BY: 5020/4441 8383 12000 5022/5 128 5023/11 5025/750 5026/14 45 5029/32
SEEN-BY: 5030/69 115 195 217 382 436 473 556 611 920 966 1016 1900 5031/47
SEEN-BY: 5033/5 21 35 5034/8 5035/10 5036/1 13 5037/21 31 36 5041/4 5042/8 13
SEEN-BY: 5045/7 5049/157 5050/9 41 5051/15 35 5053/16 5054/1 8 9 10 28 35 37
SEEN-BY: 5054/45 50 63 5055/95 5056/16 5057/1 5058/24 77 5059/20 5060/88
SEEN-BY: 5061/15 5062/10 5063/41 51 5064/5 7 35 5066/18 5070/26 66 1222
SEEN-BY: 5071/22 5075/10 5079/49 5080/1003 5081/2 5082/6 5083/13 21 5084/32
SEEN-BY: 5093/4 27 5095/1 20 5100/113 6001/3 6009/1 6023/1 6033/2727 6045/7

PATH: 5020/400 4441 52 5054/1 37