|
|
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
Tarabtsev DmitryVА какой смысл тогда держать один справочник? или это не обсуждается? ;-) тогда только бизнес-логикой разграничивать - ограничения, триггеры, ХП... Спрашивал на форуме: Одна большая или несколько малентких таблиц - получается, что с одной работать лучше.Вы неправильно поняли что вам говорили в этом обсуждении. Нельзя один и тот же подход распространять на таблицу, в которой хранятся операции и на таблицы справочников. В вашем случае, если справочники никогда не пересекаются - то лучше сделать отдельные таблицы справочников (ИМХО). Если это логически разные справочники - то им место в разных таблицах. Вариант два: контролировать корректность проставления значения из справочника - на уровне приложения. Вариант три: Добавить доп таблицы, в которых будут указаны все ID строк из справочника Вариант четыре: В справочник ввести дополнительное понятие "Категория", построить уникальный индекс по полям ID и КАТЕГОРИЯ, в основной таблице сделать FK на справочник по двум полям (СЫРЬЕ_ID, КАТЕГОРИЯ). TarabtsevУже на первом этапе вижу больше 10 справочников, а чем дальше тем их больше будет.Вот и хочется выбрать одну методику, для всех справочников. Ведь в 90% нужен только код и наименование, а для хранения особенностей исползуем справочник доп.параметров10 справочников - это почти ничто. Универсальный подход типа "EAV" при накоплении данных может аукнуться уменьшением производительности и гемором при выборках. Настолько ли он оправдан? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2008, 10:43 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
2 Tarabtsev : вот такой был топик как раз на эту тему ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2008, 11:05 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
Bely Благодарю! Обдумаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2008, 12:32 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
Относительно одной большой или несклоьких маленьких. Учет расхода. 1. Есть сущности: Производитель, Продавец, Покупатель. В качетсве покупателя, решил стать "Продавец". Наши действия: Орагнизуем одну сущность: Предприятия. В этой сущности будем указывать какое предпряитие кем может являтся. И для этого Продовца указываем, что он может быть Покупателем 2. Клиент решает, что покупателями могут быть Частники. Наши действия: расширяем понятие сущности "Предприятия", включая аттрибуты, характерные для Частника. 3. Покупателем выступил Сотрудник и его сумму покупки, нужно вычесть из ЗП... - и вот с этого этапа начинаются сложности, поскольку сщность "Сотрудники" уже реализована у нее свои коды, которые пересекаются с кодами Предприятий. Значит в таблицу продаж, надо вносить второе поле, для Сотрудника (или признака Сотрудник/ Предприятие). Надо будет переделать все запросы, чтобы разделить Сотрудников и Предприятия. И это то, что можно смоделировать, а сколько случаев заранее нельзя смоделировать!? В случае одной справочной таблицы - любые подобные изменения, абсолютно не страшны. А вот как посоветуете обезопасится от этого при нескольких таблицах? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2008, 15:46 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
TarabtsevУчет расхода. 1. Есть сущности: Производитель, Продавец, Покупатель. В качетсве покупателя, решил стать "Продавец". Наши действия: Орагнизуем одну сущность: Предприятия. В этой сущности будем указывать какое предпряитие кем может являтся. И для этого Продовца указываем, что он может быть Покупателем ........ В случае одной справочной таблицы - любые подобные изменения, абсолютно не страшны.Вы опять путаете сущности и справочники. TarabtsevА вот как посоветуете обезопасится от этого при нескольких таблицах?Детальной проработкой бизнеспроцессов ДО написания программы, составлением и утверждением ТЗ. Если пользователи сами не знают как они работают и как будут работать - то этому никто не поможет. Про гибкость программ. Абсолютной гибкости не бывает. Если ваша организация сперва торговала чебуреками, а потом решила вдруг заняться переработкой нефти - ваша система, врядли, легко адаптируется под это. Кроме этого, следует помнить, что переписав 99% кода из любой программы можно сделать тетрис. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2008, 16:01 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
Bely TarabtsevУчет расхода. 1. Есть сущности: Производитель, Продавец, Покупатель. В качетсве покупателя, решил стать "Продавец". Наши действия: Орагнизуем одну сущность: Предприятия. В этой сущности будем указывать какое предпряитие кем может являтся. И для этого Продовца указываем, что он может быть Покупателем ........ В случае одной справочной таблицы - любые подобные изменения, абсолютно не страшны.Вы опять путаете сущности и справочники. TarabtsevА вот как посоветуете обезопасится от этого при нескольких таблицах?Детальной проработкой бизнеспроцессов ДО написания программы, составлением и утверждением ТЗ. Если пользователи сами не знают как они работают и как будут работать - то этому никто не поможет. Про гибкость программ. Абсолютной гибкости не бывает. Если ваша организация сперва торговала чебуреками, а потом решила вдруг заняться переработкой нефти - ваша система, врядли, легко адаптируется под это. Кроме этого, следует помнить, что переписав 99% кода из любой программы можно сделать тетрис. Благодарю за логичный и исчерпывающий ответ! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2008, 16:17 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
TarabtsevДоброго Вам дня! Суть проблемы: Есть иерархический справочник всех ресурсов(SPR) . Есть схема производства, в которой 3 поля: 1. Сырье, 2. Полуфабрикат, 3. Компонент. Все поля ссылаются на справочник ресурсов, но для каждого поля берется своя ветка. Чтобы даные были правильные, мы должны заполнять поля, каждое из соответсвующей ветки и после проверять правильность этого,т.е. поле сырье заполнять из ветки "сырье" SPR, поле полуфабрикаты из ветки "полуфабрикаты" SPR и тд. Вот и вопрос: как сделать привязку полей с вершинами веток? Как вариант, вижу использование переменных - но, как говорится, не наш метод :) Может, что посоветуете? Советую. Не нужно ничего этого делать при такой архитектуре: не нужно заполнять поля из веток, и не нужно контролировать правильность. Нужно: для создания очередной записи "схемы производства" выбираем что угодно (как удобно пользователю) из SPR, и этот выбранный элемент помещаем в соответствующее поле записи "схемы производства". И так до бесконечности, пока пользователь не будет удовлетворен результатом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2008, 18:38 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
Bely TarabtsevУчет расхода. 1. Есть сущности: Производитель, Продавец, Покупатель. В качетсве покупателя, решил стать "Продавец". Наши действия: Орагнизуем одну сущность: Предприятия. В этой сущности будем указывать какое предпряитие кем может являтся. И для этого Продовца указываем, что он может быть Покупателем ........ В случае одной справочной таблицы - любые подобные изменения, абсолютно не страшны.Вы опять путаете сущности и справочники. TarabtsevА вот как посоветуете обезопасится от этого при нескольких таблицах?Детальной проработкой бизнеспроцессов ДО написания программы, составлением и утверждением ТЗ. Если пользователи сами не знают как они работают и как будут работать - то этому никто не поможет. Про гибкость программ. Абсолютной гибкости не бывает. Если ваша организация сперва торговала чебуреками, а потом решила вдруг заняться переработкой нефти - ваша система, врядли, легко адаптируется под это. Кроме этого, следует помнить, что переписав 99% кода из любой программы можно сделать тетрис. Теперь уже и Вы запутались. "Сущности" и "справочники"??? Не следует путать, как об этом Вы говорили выше, "сущности" (часто в ИС применяют термин "справочник") и "события", участниками которых являются "сущности" (часто в ИС применяют термин "операция"). Но, что не менее важно, хорошо бы не путать "справочники" (сущности) и "классификаторы" (сущностей)): ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2008, 18:51 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
БредСоветую. Не нужно ничего этого делать при такой архитектуре: не нужно заполнять поля из веток, и не нужно контролировать правильность. Нужно: для создания очередной записи "схемы производства" выбираем что угодно (как удобно пользователю) из SPR, и этот выбранный элемент помещаем в соответствующее поле записи "схемы производства". И так до бесконечности, пока пользователь не будет удовлетворен результатом. А не могли бы Вы пояснить почему Вы так считаете? Как минимум, пользователю будет не удобно выбирать из всего дерева. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2008, 18:53 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
Tarabtsev БредСоветую. Не нужно ничего этого делать при такой архитектуре: не нужно заполнять поля из веток, и не нужно контролировать правильность. Нужно: для создания очередной записи "схемы производства" выбираем что угодно (как удобно пользователю) из SPR, и этот выбранный элемент помещаем в соответствующее поле записи "схемы производства". И так до бесконечности, пока пользователь не будет удовлетворен результатом. А не могли бы Вы пояснить почему Вы так считаете? Как минимум, пользователю будет не удобно выбирать из всего дерева. 1) исходя из жестких условий задачи; 2) пользователю будет максимально удобно выбирать то, что ему нужно, особенно с учетом того, что эти три узла на первом уровне иерархии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2008, 19:01 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
Бред Tarabtsev БредСоветую. Не нужно ничего этого делать при такой архитектуре: не нужно заполнять поля из веток, и не нужно контролировать правильность. Нужно: для создания очередной записи "схемы производства" выбираем что угодно (как удобно пользователю) из SPR, и этот выбранный элемент помещаем в соответствующее поле записи "схемы производства". И так до бесконечности, пока пользователь не будет удовлетворен результатом. А не могли бы Вы пояснить почему Вы так считаете? Как минимум, пользователю будет не удобно выбирать из всего дерева. 1) исходя из жестких условий задачи; 2) пользователю будет максимально удобно выбирать то, что ему нужно, особенно с учетом того, что эти три узла на первом уровне иерархии. В практике встречаются ресурсы с подобными наименованиями , для уменьшения ошибок, все же, пользователя лучше ограничивать. Не факт, что эти три узла будут находится на первом уровне ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2008, 19:04 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
Tarabtsev Бред Tarabtsev БредСоветую. Не нужно ничего этого делать при такой архитектуре: не нужно заполнять поля из веток, и не нужно контролировать правильность. Нужно: для создания очередной записи "схемы производства" выбираем что угодно (как удобно пользователю) из SPR, и этот выбранный элемент помещаем в соответствующее поле записи "схемы производства". И так до бесконечности, пока пользователь не будет удовлетворен результатом. А не могли бы Вы пояснить почему Вы так считаете? Как минимум, пользователю будет не удобно выбирать из всего дерева. 1) исходя из жестких условий задачи; 2) пользователю будет максимально удобно выбирать то, что ему нужно, особенно с учетом того, что эти три узла на первом уровне иерархии. В практике встречаются ресурсы с подобными наименованиями , для уменьшения ошибок, все же, пользователя лучше ограничивать. Не факт, что эти три узла будут находится на первом уровне 1) Повторю: в соответствующее поле (с ограничениями все в порядке). 2) Интересно. Значит сначала будут круглые, зеленые, взрывоопасные, а потом эти три узла??? И как же Вы себе представляете работу пользователя при такой организации иерархии в Вашем варианте (вариантах)? Кроме того, не забывайте, что код должен быть отделен от данных, то есть при возможном перемещении "этих трех узлов" программы не должны меняться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2008, 19:54 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
softwarer TarabtsevЕсли справочником не мало, то через время, забываешь, что в каком справочнике находится - лично я с этим сталкивался - было даже, что одно и тоже хранилось в 3(!)х таблицах :) - Представил себе неземной кайф, охватывающих всех затронутых, обнаруживших, что одно и то же хранится в одной таблице, но три раза, причем со своими кодами, форматами и особенностями в каждом. Вы, вот, представляете, а я с этим живу.... Одно можно сказать - эта проблема рождается исключительно в головах и от архитектуры никак не зависит. Я видел такое и с отдельными таблицами на справочник, и с "все справочники в одной таблице". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2008, 22:09 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
TarabtsevОтносительно одной большой или несклоьких маленьких. Учет расхода. 1. Есть сущности: Производитель, Продавец, Покупатель. В качетсве покупателя, решил стать "Продавец". Наши действия: Орагнизуем одну сущность: Предприятия. В этой сущности будем указывать какое предпряитие кем может являтся. И для этого Продовца указываем, что он может быть Покупателем 2. Клиент решает, что покупателями могут быть Частники. Наши действия: расширяем понятие сущности "Предприятия", включая аттрибуты, характерные для Частника. 3. Покупателем выступил Сотрудник и его сумму покупки, нужно вычесть из ЗП... - и вот с этого этапа начинаются сложности, поскольку сщность "Сотрудники" уже реализована у нее свои коды, которые пересекаются с кодами Предприятий. Значит в таблицу продаж, надо вносить второе поле, для Сотрудника (или признака Сотрудник/ Предприятие). Надо будет переделать все запросы, чтобы разделить Сотрудников и Предприятия. И это то, что можно смоделировать, а сколько случаев заранее нельзя смоделировать!? В случае одной справочной таблицы - любые подобные изменения, абсолютно не страшны. А вот как посоветуете обезопасится от этого при нескольких таблицах? Тут-то как раз все просто. "Контракторы" - одна таблица "Юрики","Физики","Банки","Хренанки" - дополнительные таблицы, связанные с "контрактором" определяющей связью (если ничего не путаю). "роли" - роли контракторов, "Покупатель,продавец,сотрудник,матрудник" - всего лишь типы ролей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2008, 22:16 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
Николай1Одно можно сказать - эта проблема рождается исключительно в головах и от архитектуры никак не зависит. Вот и я именно об этом. Форма обусловлена тем, что мои собеседники часто делают такую ошибку, и она успела мне весьма надоесть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2008, 03:51 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
БредТеперь уже и Вы запутались. "Сущности" и "справочники"??? Не следует путать, как об этом Вы говорили выше, "сущности" (часто в ИС применяют термин "справочник") и "события", участниками которых являются "сущности" (часто в ИС применяют термин "операция"). Но, что не менее важно, хорошо бы не путать "справочники" (сущности) и "классификаторы" (сущностей)):Сейчас мы об этом говорить не будем, потому что говорить об этом следует не сейчас. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2008, 10:35 |
|
||
|
|
start [/forum/topic.php?fid=32&msg=35399790&tid=1543791]: |
0ms |
get settings: |
7ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
151ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
38ms |
get tp. blocked users: |
1ms |
| others: | 208ms |
| total: | 435ms |
| 0 / 0 |
