|
|
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
Доброго Вам дня! Суть проблемы: Есть иерархический справочник всех ресурсов(SPR) . Есть схема производства, в которой 3 поля: 1. Сырье, 2. Полуфабрикат, 3. Компонент. Все поля ссылаются на справочник ресурсов, но для каждого поля берется своя ветка. Чтобы даные были правильные, мы должны заполнять поля, каждое из соответсвующей ветки и после проверять правильность этого,т.е. поле сырье заполнять из ветки "сырье" SPR, поле полуфабрикаты из ветки "полуфабрикаты" SPR и тд. Вот и вопрос: как сделать привязку полей с вершинами веток? Как вариант, вижу использование переменных - но, как говорится, не наш метод :) Может, что посоветуете? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2008, 19:18 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
Tarabtsevиспользование переменных Правильней: предопределенных констант ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2008, 20:34 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
а что, артикул не может быть сырьем и полуфабрикатом одновременно? для разных ТП, естественно :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2008, 11:38 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
DmitryVа что, артикул не может быть сырьем и полуфабрикатом одновременно? для разных ТП, естественно :-) В данном случае нет - все разграничено ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2008, 12:56 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
А какой смысл тогда держать один справочник? или это не обсуждается? ;-) тогда только бизнес-логикой разграничивать - ограничения, триггеры, ХП... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2008, 13:50 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
DmitryVА какой смысл тогда держать один справочник? или это не обсуждается? ;-) тогда только бизнес-логикой разграничивать - ограничения, триггеры, ХП... Спрашивал на форуме: Одна большая или несколько малентких таблиц - получается, что с одной работать лучше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2008, 13:56 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
DmitryVтогда только бизнес-логикой разграничивать - ограничения, триггеры, ХП... Сейчас надо выделять 3 ветви (т.е. их вершины), соответсвенно, надо помнить 3 значения. Со временем появятся новые условия и надо будет сохранять новые вершины, значит опять добавлять переменные. А если решат изменить ветку, то надо будет и переменную менять. Это не так сложно сделать и руками, но хочется как-то автоматизировать, чтоб уменьшить вероятность ошибки. Один вариант уже вижу: использование доп.таблицы, в которой будет связка: таблица - поле - вершина ветки справочника. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2008, 14:07 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
Так все-таки, что у вас за система: CRM или технологические процессы? Что-то мне кажется, что у Вас сейчас в одну таблицу сваливаются 3 различные сущности... К тому же, не совсем понятно, откуда могут возникнуть доп.вершины справочника и как они будут учитываться в основной таблице... Опишите задачу подробнее ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2008, 14:35 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
DmitryVТак все-таки, что у вас за система: CRM или технологические процессы? Что-то мне кажется, что у Вас сейчас в одну таблицу сваливаются 3 различные сущности... К тому же, не совсем понятно, откуда могут возникнуть доп.вершины справочника и как они будут учитываться в основной таблице... Опишите задачу подробнее Сейчас только приступаю к разработке и выбираю модель данных - приведенная схема это просто пример - заранее вижу, что подобная будет. Разработка будет идти по этапно: 1. Просто учет прихода, расхода. 2. WMS. 3. производство. 4. планирование. 5. хез Уже на первом этапе вижу больше 10 справочников, а чем дальше тем их больше будет.Вот и хочется выбрать одну методику, для всех справочников. Ведь в 90% нужен только код и наименование, а для хранения особенностей исползуем справочник доп.параметров ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2008, 14:46 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
Я не вижу большой проблемы в большом количестве справочников... Подгонять все справочники под одну гребенку тоже, на мой взгляд, не стоит, уж больно разные они бывают... В Вашем случае я бы добавил в справочник ТМЦ тип артикула - сырье, полуфабрикат и т.д. и решал бы все на уровне бизнес-логики. Правда, Вы так и не рассказали, как в схеме "сырье-полуфабрикат-компонент" будете учитывать появление новых типов ТМЦ :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2008, 15:25 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
TarabtsevСуть проблемы: Есть иерархический справочник всех ресурсов(SPR) . Есть схема производства, в которой 3 поля: 1. Сырье, 2. Полуфабрикат, 3. Компонент. Все поля ссылаются на справочник ресурсов, но для каждого поля берется своя ветка. ... Вот и вопрос: как сделать привязку полей с вершинами веток? Как вариант, вижу использование переменных - но, как говорится, не наш метод :) Может, что посоветуете? С учетом ваших дальнейших описаний посоветую следующее: 1. Таблица SPR дополняется признаком-ссылкой на таблицу, описывающую тип ресурсов {сырье, полуфабрикат, компонент}. 2. Тогда в таблице схем производства заполнение любого из полей может осуществляться выборкой из таблицы SPR с ограничением по типу ресурсов. ... Если вы хотите физически ограничить целостность в БД, тогда: 1. Таблица SPR дополняется альтернативным ключом {идентификатор_ресурса,тип_ресурса} 2. Таблица схем производства дополняется полем "тип_ресурса" и дополнительными внешними ключами на таблицу SPR по полям {идентификатор_ресурса,тип_ресурса}. Таковы могут быть технические реализации вашего "алгоритма". ... А вообще это не очень удачное проектирование. Давайте рассмотрим вообще схему производства: Грубо говоря, производство - это черный ящик, на входе которого поступает перечень сырья в каких-то пропорциях, а на выходе перечень продуктов и перечень отходов в других пропорциях. Имеется дополнительное ограничение - всегда соблюдается материальный баланс производства. Тогда проектировать будем исходя из этих подходов: item_type (id, name) - тип сырья, материалов и продуктов, здесь же может быть перечень типов отходов производства; item (id, name, id_parent, id_item_type) - сырье, материалы и продукты, нужен внешний ключ на item_type и альтернативный ключ на id и id_item_type; recipe (id, name, date, ...) - перечень рецептов (схем) производства; recipe_raw (id, id_recipe, id_item, id_item_type, ...) - перечень сырья для рецепта, нужен внешний ключ на пару id_item и id_item_type; recipe_product (id, id_recipe, id_item, id_item_type, ...) - перечень продуктов и отходов производства, нужен внешний ключ на пару id_item и id_item_type; Количественные показатели для соблюдения материального баланса внесите самостоятельно. Успехов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2008, 15:30 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
DmitryVЯ не вижу большой проблемы в большом количестве справочников... Если справочником не мало, то через время, забываешь, что в каком справочнике находится - лично я с этим сталкивался - было даже, что одно и тоже хранилось в 3(!)х таблицах :) - приходлось схему на стенку вешать. Да и с одной таблицей гораздо легче работать: одна форма, один набор триггеров и тд DmitryV... Подгонять все справочники под одну гребенку тоже, на мой взгляд, не стоит, уж больно разные они бывают... Это пока и останавливает меня от реализации. Еще обдумываю все возможные ситуации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2008, 15:37 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
Tarabtsev Если справочником не мало, то через время, забываешь, что в каком справочнике находится - лично я с этим сталкивался - было даже, что одно и тоже хранилось в 3(!)х таблицах :) - приходлось схему на стенку вешать. Есть такая вещь - словарь данных называется :-) Tarabtsev Да и с одной таблицей гораздо легче работать: одна форма, один набор триггеров и тд Ведение словарей - это отдельная тема :-) Как в одном триггере или даже их наборе учесть все нюансы совершенно разных словарей я не очень себе представляю.... зато что из таких попыток получается - видел неоднократно :-) а по существу _VVP_ выше уже написал :-) берете за основу и дорабатываете идею до своей реализации ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2008, 15:56 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
_VVP_ Благодарю , обдумаю. Успехов! DmitryV... зато что из таких попыток получается - видел неоднократно :-) Пример можно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2008, 16:02 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
Tarabtsev Пример можно? Ну не буду же я сюда код выкладывать :-) да и давно это было... Вы и сами в сосотоянии представить, мне кажется, что получится, если в одном месте пытаются работать и с плоскими словарями "код-значение", и с иерархическими словарями на десяток уровней, и со словарями с доп.параметрами... Все это было сведено в одну таблицу вида "код в таблице-номер словаря-код в словаре-доп.поле1(код родителя)-доп.поля...", где словарей было несколько десятков, записей в них - несколько десятков тысяч. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2008, 16:17 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
DmitryV в одном месте пытаются работать и с плоскими словарями "код-значение", и с иерархическими словарями на десяток уровней, и со словарями с доп.параметрами... Все это было сведено в одну таблицу вида "код в таблице-номер словаря-код в словаре-доп.поле1(код родителя)-доп.поля...", где словарей было несколько десятков, записей в них - несколько десятков тысяч. Проблем не вижу - разве, что халатное отношение к написание кода и плохое тестирование. Но(!) Исправление ошибки в одном месте - исправит ошибку везде. А халатное отношение к написание кода и плохое тестирование скажется и при другой реализации - но ошибку прийдется исправлять во всех местах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2008, 16:34 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
В любом случае Вам виднее, как делать ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2008, 16:48 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
Благодарю Вас за помощь! DmitryVВ любом случае Вам виднее, как делать ;-) Думаю, думаю, думаю. Хотя, наверное, все же правильней - сделать, а там видно будет, поскольку, мало ли что завтра будет. А так, переделать всегда можно + доп. заработок на будущее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2008, 16:55 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
Tarabtsevдоп. заработок на будущее. или матюки сопровождающих ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2008, 18:21 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
egorych Tarabtsevдоп. заработок на будущее. или матюки сопровождающих И все же, с идеальных программ люди меньше получают. А работать приходится, не только ради удовольствия и правильности, но и ради денег От сопровождающих многое(!), конечно, зависит: могут своим нытьем и ничегонеделанием классный реально проект завалить и наоборот: дерьмовый проект постоянно подталкивая, пиаря вытащить в классный! Так что, сопоровождающих всегда подкармливаь надо, чтобы не матюкались ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2008, 18:39 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
TarabtsevЕсли справочником не мало, то через время, забываешь, что в каком справочнике находится - лично я с этим сталкивался - было даже, что одно и тоже хранилось в 3(!)х таблицах :) - Представил себе неземной кайф, охватывающих всех затронутых, обнаруживших, что одно и то же хранится в одной таблице, но три раза, причем со своими кодами, форматами и особенностями в каждом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2008, 21:05 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
softwarerПредставил себе неземной кайф, охватывающих всех затронутых, обнаруживших, что одно и то же хранится в одной таблице, но три раза, причем со своими кодами, форматами и особенностями в каждом. Конечно же Вы правы - такое возможно. Но все же , вероятность меньше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2008, 21:10 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
Перешел уже к разработке прав доступа и безопасности. Очень сильно обрадовался, что если использовать только одну справочную таблицу - эти вопросы решаются элементарно. А именно. Имеем 2 таблицы Код: plaintext 1. 2. 3. 4. 5. 6. 7. Код: plaintext 1. 2. 3. 4. 5. 6. Код: plaintext 1. 2. 3. 4. 5. Теперь при любом доступе к SPRS, будь то выборка из справочника или выборка бизнес-операций, мы всегда будем выбирать, только то, на что у пользователя есть право. Так же, и изменять мы можем только то, на что есть право. Учитывая, что используем иерархический справочник, то очень легко будет настраивать доступ группам пользователей, и тд. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2008, 16:56 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
эээ.... а какой объем справочников ожидается? и сколько пользователей? ;-) смысл раздачи прав на КАЖДУЮ строку СПРАВОЧНИКА? может, права раздавать все-таки на данные? :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2008, 09:56 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#18+
DmitryVсмысл раздачи прав на КАЖДУЮ строку СПРАВОЧНИКА? А если в справочнике только 10 товаров, и каждый менеджер занимается только своим товаром? Зачем ему показывать остальные 9? Бывает и такое DmitryVможет, права раздавать все-таки на данные? :-) А какой критерий раздела прав для данных? - опять таки справочник. :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2008, 10:05 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=35388808&tid=1543791]: |
0ms |
get settings: |
7ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
23ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
| others: | 222ms |
| total: | 325ms |

| 0 / 0 |
