|
|
|
Прошу совета
|
|||
|---|---|---|---|
|
#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 |
|
||
|
Прошу совета
|
|||
|---|---|---|---|
|
#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?all=1&fid=32&tid=1543791]: |
0ms |
get settings: |
7ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
182ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
| others: | 222ms |
| total: | 485ms |

| 0 / 0 |
