|
|
|
Проектирование атомарных справочников...
|
|||
|---|---|---|---|
|
#18+
ViPRosнежные, вы любовь на скрипки лож<> 1. всё ложите в "универсальное хранилище" а-ля еав ? (и приравненные) 2. таки накатываете ддл (не руками, естественно), когда определяетесь со своим конструктором ? 3. что-то перпендикулярно и 1 и 2 ? <> кортинко на картинке видим как фиксированные сущности, так и еав, с расщеплением значений св-в по типам. ну, раскладка необязательного по еав - не секрет даже 1С сподвиглось если на этом "динамический классификатор блаблабла" заканчивается -- то это грустная шутка что происходит, когда мы определились с закостенением некой части "фигни" ? забираете в монопольный, натравливаете ддл, и реорганизуете данные ? или так всё по еавам и валяется ? хотя бы not null для еав-поля сумеете сорганизовать ? так чтобы бетонно, есс-но ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2014, 08:19 |
|
||
|
Проектирование атомарных справочников...
|
|||
|---|---|---|---|
|
#18+
Кот МатроскинЯ обьясняю руководству Маши и Пети "Если Вы приобретаете нашу систему - Вы можете делать ряд настроек силами ваших Маши и Пети, а не заказывать доработку у нас за 100500 денег. При этом Маша и Петя не повредят безвозвратно вашу базу. К системе мы прилагаем в документации ряд скриншотов для Маши и описание API для Пети. с одной стороны, если используется ЕАВ, то логично и справочники держать в одной структуре. Но если ЕАВ не является основой системы, то такой подход, имхо ничего не дает. Если уж так необходима возможность для пользователей дополнять модель данных (что врядли, в большинстве случаев не более чем маркетинговый ход), можно справочники и ссылочные поля создавать "физически", предоставляя пользователям соответствующий интерфейс. (какая, по большому счету разница, на каком уровне Маша с Петей испортятдополнят заложенную структуру данных, на уровне ЕАВ или на уровне DDL) Но при этом хотя бы сохранится целостность данных на уровне БД. Еще, по теме топика, любой "атомарный" справочник, по мере развития системы может стать совсем не атомарным. Что делать будете? Выводить справочник из атомарных? Или лить специфические поля в общую кучу? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2014, 09:06 |
|
||
|
Проектирование атомарных справочников...
|
|||
|---|---|---|---|
|
#18+
Мы поначалу тоже все "атомарные справочники" объединили в одну таблицу с типичной структурой (id, type, code, title, shorttitle, actual/use итп). Вроде как хорошо, "сэкономили" на количестве таблиц. Придумали даже такую штуку, чтобы FK работали правильно - id сделали не случайным (autoinc итп), а по принципу type * 1000 + code, т.е. 445002 как бы обозначало, что справочник номер 445, а код элемента справочника - 2. И чтобы а таблица не могла сослаться на "чужой" элемент прописывали помимо FK еще и check, вида material_id % 1000 = 445. Ну и полагали, что элементов справочника не должно превышать 1000 (честно говоря, не вижу смысла в справочниках, у которых элементов очень много). Но потом начали появляться следующие вещи - каждый "атомарный справочник" в процессе развития системы стремился стать самостоятельной сущностью, у него появлялся первый дополнительный атрибут (завели еще одно "универсальное" поле), потом второй, потом более хитрые ограничения внутри его множества значений итп. Потихоньку начали отдирать от большой таблицы по одному. В конце концов решили полностью отказаться от подхода. Это, кстати, имело и дополнительные преимущества в виде более понятной модели данных, и неуклюжие ER-диаграммы с кучей "случайных" связей к одной таблице стали выглядеть прозрачнее. Правда подход с диапазоном значений оставили - понравился :). Но как бы подход "куча справочников - одна таблица" пока со счетов не сбрасываю, вдруг есть такие задачи, где такой подход вполне может быть применим. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2014, 09:30 |
|
||
|
Проектирование атомарных справочников...
|
|||
|---|---|---|---|
|
#18+
на литавру ложит грубыйViPRosпропущено... кортинко на картинке видим как фиксированные сущности, так и еав, с расщеплением значений св-в по типам. ну, раскладка необязательного по еав - не секрет даже 1С сподвиглось если на этом "динамический классификатор блаблабла" заканчивается -- то это грустная шутка что происходит, когда мы определились с закостенением некой части "фигни" ? забираете в монопольный, натравливаете ддл, и реорганизуете данные ? или так всё по еавам и валяется ? хотя бы not null для еав-поля сумеете сорганизовать ? так чтобы бетонно, есс-но я тебе показал все 3 твоих + автоматически/принудительную реорганизацию в ОБЕИХ направлениях зависимости от режима функционирования на читай, писал когда то вместо ТЗ, щоб на бабки выйти ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2014, 09:31 |
|
||
|
Проектирование атомарных справочников...
|
|||
|---|---|---|---|
|
#18+
Goffmanс одной стороны, если используется ЕАВ, то логично и справочники держать в одной структуре. Но если ЕАВ не является основой системы, то такой подход, имхо ничего не дает. Применительно к справочнику ключ/значение без разницы лежит ли EAV в основе. Тем более EAV может дополнять основною модель, а не лежать в основе. GoffmanЕще, по теме топика, любой "атомарный" справочник, по мере развития системы может стать совсем не атомарным. Что делать будете? Выводить справочник из атомарных? Или лить специфические поля в общую кучу?Конечно требуется выводить, поскольку он уже не будет вписываться в эту структуру. На моей памяти проблем с этим не возникало. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2014, 10:57 |
|
||
|
Проектирование атомарных справочников...
|
|||
|---|---|---|---|
|
#18+
Infernal V. RavenПрименительно к справочнику ключ/значение без разницы лежит ли EAV в основе. Тем более EAV может дополнять основною модель, а не лежать в основе. Я имел в виду, что подход к проектированию справочников должен быть таким же, что и при построении основной системы. Исключения разумеется могут быть, но обоснованные. Infernal V. RavenКонечно требуется выводить, поскольку он уже не будет вписываться в эту структуру. На моей памяти проблем с этим не возникало. Ну если не считать лишнюю работу по переделке структуры данных и приложений, то да - проблем нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2014, 11:26 |
|
||
|
Проектирование атомарных справочников...
|
|||
|---|---|---|---|
|
#18+
GoffmanЯ имел в виду, что подход к проектированию справочников должен быть таким же, что и при построении основной системы.Исключения разумеется могут быть, но обоснованные.Не должен. Нужно руководствоваться здравым смыслом и если он говорит о том что выгоднее сделать часть справочников в виде ключ/значение в одной таблице, а другие справочники в табличном виде - так делать и нужно. Тоже самое применительно к EAV. GoffmanV. RavenНу если не считать лишнюю работу по переделке структуры данных и приложений, то да - проблем нет.Делать один справочник ключ/значение выгоднее по времени. Если есть подозрение, что справочник должен быть расширен - нужно выводить в отдельную таблицу сразу. Методику оценки я приводил уже. В подавляющем большинстве случаев справочники "не переезжают" поэтому это оправдано. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2014, 12:39 |
|
||
|
Проектирование атомарных справочников...
|
|||
|---|---|---|---|
|
#18+
Infernal V. Raven Нужно руководствоваться здравым смыслом и если он говорит о том что выгоднее сделать часть справочников в виде ключ/значение в одной таблице, а другие справочники в табличном виде - так делать и нужно. Тоже самое применительно к EAV. Выгода как я понимаю заключается только в экономии времени. Ну да, такой подход позволяет с экономить на одном справочнике минут 10-15. С другой стороны мы имеем: * Отсутствие целостности данных на уровне БД. Этот пункт особенно обостряется, если с базой будет работать (даже в перспективе) несколько приложений * Потенциальная проблема расширения любого справочника, со всеми прелестями изменения схемы БД на работающей системе. * Отсутствие четкой и понятной схемы данных - имея только DDL, сложно разобраться какая таблица на какой справочник ссылается. По всем параметрам, "классический" подход к справочникам более качественный, с точки зрения дальнейшей работы с данными. Единственный "недостаток" - небольшие затраты на написание скрипта DDL.Но даже в этом случае, если кто-то штампует эти справочники пачками, этот процесс можно автоматизировать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2014, 14:13 |
|
||
|
Проектирование атомарных справочников...
|
|||
|---|---|---|---|
|
#18+
Goffman* Отсутствие целостности данных на уровне БД. Этот пункт особенно обостряется, если с базой будет работать (даже в перспективе) несколько приложенийЭто не так. Во-первых - контроль целостности напрямую зависит от методики работы с данными. Даже в "своих" приложениях помимо FK существуют дополнительные правила логической проверки вводимых значений. Во-вторых - коллеги здесь уже писали, что FK использовать в этой схеме можно, а некоторые говорили, что еще и нужно. Goffman* Потенциальная проблема расширения любого справочника, со всеми прелестями изменения схемы БД на работающей системе.Само собой нужно оценивать - это задача проектировщика и архитектора. Потенциально возможно все, но, надеюсь, Вы же не будете каждую систему из-за этого делать на EAV-модели? Тоже самое применительно к общему справочнику. Goffman* Отсутствие четкой и понятной схемы данных - имея только DDL, сложно разобраться какая таблица на какой справочник ссылается.Достаточно использовать понятную систему наименований (читай стандарт) и все становится понятным. Собственно система названий для всех объектов делают структуры читаемыми. GoffmanПо всем параметрам, "классический" подход к справочникам более качественный, с точки зрения дальнейшей работы с данными. Единственный "недостаток" - небольшие затраты на написание скрипта DDL.Но даже в этом случае, если кто-то штампует эти справочники пачками, этот процесс можно автоматизировать.Ну Вы почитайте, тут уже говорилось о выигрышах, что по десять раз писать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2014, 17:08 |
|
||
|
Проектирование атомарных справочников...
|
|||
|---|---|---|---|
|
#18+
GoffmanВыгода как я понимаю заключается только в экономии времени. Ну да, такой подход позволяет с экономить на одном справочнике минут 10-15. Не всегда так как у Вас. Часто - это выбор между "заплатить разработчику и прождать две недели" (со всеми прелестями изменения схемы БД на работающей системе (с)) или дать указание своему админу, что мгновенно и бесплатно... GoffmanС другой стороны мы имеем: * Отсутствие целостности данных на уровне БД. Этот пункт особенно обостряется, если с базой будет работать (даже в перспективе) несколько приложенийНу или отсутствие этого отсутствия, когда все ОЦ соблюдены. В таком случае и другие приложения могут этим пользоваться, т.к. никакой логики обработки данных на клиенте нет. Goffman* Потенциальная проблема расширения любого справочника, со всеми прелестями изменения схемы БД на работающей системе.Тут уже платить придется, это оправданно. Goffman* Отсутствие четкой и понятной схемы данных - имея только DDL, сложно разобраться какая таблица на какой справочник ссылается.Разбросайте по разным справочникам. Например, Кота Матроскина больше беспокоит проблема с грантами, Вас - с констрейнтами и понятностью схемы... Отсюда выбор - либо много таблиц и вьюха их объединяющая, либо одна таблица... GoffmanЕдинственный "недостаток" - небольшие затраты на написание скрипта DDL.Но даже в этом случае, если кто-то штампует эти справочники пачками, этот процесс можно автоматизировать.Для этого нужны права на create (со всеми прелестями изменения схемы БД на работающей системе (с)). Они, зачастую, только у разработчика. Он, очевидно, не против, чтобы процесс переправки ему финансов был автоматизирован... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2014, 10:20 |
|
||
|
Проектирование атомарных справочников...
|
|||
|---|---|---|---|
|
#18+
ChAЕсли мы говорим о целостной и непротиворечивой модели данных(МД) ПО, то ни о какой кнопке "Создание нового справочника" говорить нельзя. В контексте топика это подразумевает создание новой сущности, не связанной ни с какими другими, т.е., по сути, не входящая в МД ПО. Для её включения необходимо связать с другими сущностями, что требует создания в этих сущностях соответствующего атрибута(ов), хранящего ссылку(и) на элемент(ы) нового классификатора.1. Мне показалось, что в контексте этого топика это не обязательно подразумевает создание новой сущности. 2. Сущность в общем случае может быть связана с другими посредством отношения многие-ко-многим, "хранящего ссылку(и) на элемент(ы) нового классификатора". ChAПроблема в том, что глобальный классификатор всего и вся превращает реляционную модель в "кашу"Нет, модель не превращает. Не всегда превращает. Возможны случаи, когда не превращает. Если говорить о данных, то в кашу при умелом подходе можно превратить даже справочник полов, напичкав его гермафродитами, трансвеститами и кастратами... ChA, которая требует добавления сложной метамодели и написания промежуточного слоя для интерпретации и обработки данных. Таким образом МД ПО, которая нормально реализуема в терминах реляционной МД, зачем-то поднимается на уровень выше и там управляется неким "универсальным" программным кодомДа не поднимается ни на какой уровень выше, все решается средствами СУБД. Я действительно не понимаю о каком "универсальном коде" Вы говорите. Ну и в заключение наш общий рефрен: ChAПричём это вовсе не исключает, что такого категорически не надо делать, просто, на мой взгляд, этим слишком часто злоупотребляют. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2014, 11:11 |
|
||
|
Проектирование атомарных справочников...
|
|||
|---|---|---|---|
|
#18+
Sgt.PepperChAЕсли мы говорим о целостной и непротиворечивой модели данных(МД) ПО, то ни о какой кнопке "Создание нового справочника" говорить нельзя. В контексте топика это подразумевает создание новой сущности, не связанной ни с какими другими, т.е., по сути, не входящая в МД ПО. Для её включения необходимо связать с другими сущностями, что требует создания в этих сущностях соответствующего атрибута(ов), хранящего ссылку(и) на элемент(ы) нового классификатора.1. Мне показалось, что в контексте этого топика это не обязательно подразумевает создание новой сущности.IMHO, любой новый справочник, включая классификаторы, является новой сущностью. Он описывает некое новое измерение сущностей, тип данных, если угодно. Убедительных доказательств обратного я здесь не увидел, если нетрудно приведите пример, когда добавление нового справочника не приводит к появлению новой сущности. Sgt.Pepper2. Сущность в общем случае может быть связана с другими посредством отношения многие-ко-многим, "хранящего ссылку(и) на элемент(ы) нового классификатора".Там жеChAИногда даже отдельной сущности для реализации связи между новым классификатором и сущностью, его использующей.Но это нисколько не отнимает тот факт, что все сущности будут связаны в единую модель. Ни одна не останется "висеть" в воздухе. Повторюсь, добавление нового справочника влечёт за собой не только появление новой сущности, но и её обязательную связь с другими сущностями модели, прямо или косвенно.Sgt.PepperChAПроблема в том, что глобальный классификатор всего и вся превращает реляционную модель в "кашу"Нет, модель не превращает. Не всегда превращает. Возможны случаи, когда не превращает.Простите, но это не аргумент, это забалтывание. И на "а" бывает и на "я" бывает. Проще всего привести убедительный пример, если он есть.Sgt.PepperЕсли говорить о данных, то в кашу при умелом подходе можно превратить даже справочник полов, напичкав его гермафродитами, трансвеститами и кастратами...Пример с полом как раз и показывает, что в разных случаях есть своя шкала измерений, за которой кроется своя семантика. И пол для паспорта и,например, сексолога это принципиально разные шкалы. Если в первом случае, обычно достаточно идентифицировать отсутствие или наличие МПХ, исключая нестандартные ситуации, то во втором его наличие не играет практически никакой роли. Совпадение некоторых "значений" в данном случае достаточно случайно. Это так же как могут быть красное яблоко и красный трактора, где "красный" - это всего лишь значение и на практике такое совпадение вряд ли не является веским основанием объединить трактора и яблоки в одном классификаторе.Sgt.PepperChA, которая требует добавления сложной метамодели и написания промежуточного слоя для интерпретации и обработки данных. Таким образом МД ПО, которая нормально реализуема в терминах реляционной МД, зачем-то поднимается на уровень выше и там управляется неким "универсальным" программным кодомДа не поднимается ни на какой уровень выше, все решается средствами СУБД.С таким же успехом можно сказать что скажем, машинный код и Паскаль - языки одного уровня, всё ведь всё равно решается на уровне процессора. Тоже позиция. Значит у нас разные понятия об уровне языка. Или точнее, у вас их нет, ведь всё равно всё решается процессором.Sgt.PepperЯ действительно не понимаю о каком "универсальном коде" Вы говорите.Мне казалось очевидным, что это код на SQL, включая диалекты, который должен контролировать работу с данными и доступ к ним. Если сущность реализована стандартно, как таблица, то об этом "заботятся" встроенные механизмы РСУБД посредством декларативного объявления, а не написанием императивного кода. Впрочем, об этом уже столько раз было сказано, в частности - SERG1257, что, честно говоря, я не понимаю, зачем вновь пишу, как мне казалось, очевидные вещи. Sgt.Pepperнаш общий рефренChAПричём это вовсе не исключает, что такого категорически не надо делать, просто, на мой взгляд, этим слишком часто злоупотребляют.Боюсь, только звучит он для нас по-разному. Для меня "глобальный классификатор" исключительный случай и относится к дополнительному функционалу, в частности, как упоминалось ранее, для реализации семантической сети, но никак не к моделировании предметной области. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2014, 13:06 |
|
||
|
Проектирование атомарных справочников...
|
|||
|---|---|---|---|
|
#18+
ChASgt.Pepperнаш общий рефренпропущено... Боюсь, только звучит он для нас по-разному. Для меня "глобальный классификатор" исключительный случай и относится к дополнительному функционалу, в частности, как упоминалось ранее, для реализации семантической сети, но никак не к моделировании предметной области.Никак не пойму почему Вы считаете, что для меня иначе?.. Я именно про семантическую сеть... ChAIMHO, любой новый справочник, включая классификаторы, является новой сущностью. Он описывает некое новое измерение сущностей, тип данных, если угодно. Убедительных доказательств обратного я здесь не увидел, если нетрудно приведите пример, когда добавление нового справочника не приводит к появлению новой сущности.На логическом уровне это может быть добавление новой строки в таблицу. Считать ли это новой сущностью - вопрос философский, коллеги уже об этом намекали. ChAПовторюсь, добавление нового справочника влечёт за собой не только появление новой сущности, но и её обязательную связь с другими сущностями модели, прямо или косвенно.Косвенно она с ними уже связана, может быть более уместно сказать, что не косвенно, а "прямо" через таблицу n:n. Сущность "страны" Вас устраивает? Изначально создано отношение id_country, id_справочника, id_значение_справочника. id_country+id_справочника = pk. Пользователем (админом) добавлен новый справочник и он уже связан (уж не берусь судить прямо или косвенно) с таблицей стран. Где нарушение РМД?.. Где тут "висит в воздухе"?.. Где зависимость от приложения?.. Напоминаю, что я рассматриваю это только как "семантическую сеть", без логики обработки таких данных... ChAПростите, но это не аргумент, это забалтывание. И на "а" бывает и на "я" бывает. Проще всего привести убедительный пример, если он есть.Чуть выше привел, да и не раз он уже приводился. Что-то непонятно? Неужели нужен sql-код?.. ChAЕсли сущность реализована стандартно, как таблица, то об этом "заботятся" встроенные механизмы РСУБД посредством декларативного объявления, а не написанием императивного кода. Впрочем, об этом уже столько раз было сказано, в частности - SERG1257, что, честно говоря, я не понимаю, зачем вновь пишу, как мне казалось, очевидные вещи.Так я и SERG1257 не понимаю так же как и Вас - где здесь императивный код?.. В инсерте строки в таблицу?.. Чем не декларативно объявление суперсправочника в виде id_справочника, id_значение, строка_значение?.. Где я сбежал за пределы СУБД?... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2014, 13:41 |
|
||
|
Проектирование атомарных справочников...
|
|||
|---|---|---|---|
|
#18+
Sgt.PepperНе всегда так как у Вас. Часто - это выбор между "заплатить разработчику и прождать две недели" или дать указание своему админу, что мгновенно и бесплатно... Признаться, не могу себе представить реальное применение такому подходу. Справочник ведь нужен не сам по себе, его нужно увязывать с общей моделью данных, то есть делать на него ссылочные поля в таблицах, дорабатывать под него юзерфейс, отчеты и т.д. Уж не говорю о внедрении и сопровождении "данного решения". И всем этим будет заниматься "местный админ"? Я вас умоляю... :) Sgt.PepperНу или отсутствие этого отсутствия, когда все ОЦ соблюдены. В таком случае и другие приложения могут этим пользоваться, т.к. никакой логики обработки данных на клиенте нет. Под ОЦ вы вероятно подразумеваете FK? Но ведь это мало в случае совмещенного справочника. У нас в одном справочнике лежат наименования валют и марки цемента. Кто нам помешает в поле, отвечающее за марку цемента, записать ссылку на валюту? Уж точно не FK. Получается механизмы целостности придется реализовывать на другом уровне - ХП, приложение и т.п. Sgt.PepperПотенциальная проблема расширения любого справочника, со всеми прелестями изменения схемы БД на работающей системе -Тут уже платить придется, это оправданно. пожалеть 15 минут при разработке, имея шансы заработать потом недельный гемор - это по вашему оправдано? ну конечно кому как... Sgt.PepperНапример, Кота Матроскина больше беспокоит проблема с грантами, Вас - с констрейнтами и понятностью схемы... Согласен. Так как не существует определенных стандартов на разработку ПО, разработчика волнуют больше собственные интересы, чем интересы заказчика. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2014, 22:31 |
|
||
|
Проектирование атомарных справочников...
|
|||
|---|---|---|---|
|
#18+
GoffmanПризнаться, не могу себе представить реальное применение такому подходу. Справочник ведь нужен не сам по себе, его нужно увязывать с общей моделью данных, то есть делать на него ссылочные поля в таблицах, дорабатывать под него юзерфейс, отчеты и т.д. Уж не говорю о внедрении и сопровождении "данного решения". И всем этим будет заниматься "местный админ"? Я вас умоляю... :) Зачастую, конечно, этого будет недостаточно. В первую очередь это упрощение работы разработчиков. Скажем паттерн проектирования и разработки. GoffmanПод ОЦ вы вероятно подразумеваете FK? Но ведь это мало в случае совмещенного справочника. У нас в одном справочнике лежат наименования валют и марки цемента. Кто нам помешает в поле, отвечающее за марку цемента, записать ссылку на валюту? Уж точно не FK. Получается механизмы целостности придется реализовывать на другом уровне - ХП, приложение и т.п.FK помешает. Читайте, описывалось ранее. Goffmanпожалеть 15 минут при разработке, имея шансы заработать потом недельный гемор - это по вашему оправдано? ну конечно кому как...Удивляюсь, почему такая, по сути, простая задача требует у Вас неделю работы. Может вы что-то не так делаете? GoffmanТак как не существует определенных стандартов на разработку ПО, ...Вообще-то существуют. Попробуйте гугл. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2014, 10:03 |
|
||
|
Проектирование атомарных справочников...
|
|||
|---|---|---|---|
|
#18+
Infernal V. RavenGoffmanТак как не существует определенных стандартов на разработку ПО, ...Вообще-то существуют. Попробуйте гугл.Не существуют. Есть некоторые общие (укрупненные) рекомендации. Не более. В любом продукте можно найти кучу отступлений от "правил". Много уникальных продуктов и линеек технологий. И в них свои стандарты. Даже такая, казалось бы более определенная вещь как ГУИ и та не имеет четких стандартов. Нужны примеры ? Возьмите до предела банальный чекбокс. Есть единый стандарт ? Да хрен там !!! В разных продуктах у чекбоксов поведение может отличаться. Чем ? Фокус есть/нет. Переключение пробелом есть/нет. Свертывание строк есть/нет. Грей есть/нет. Клик на тексте есть/нет. А это всего лишь сраный чекбокс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2014, 11:44 |
|
||
|
Проектирование атомарных справочников...
|
|||
|---|---|---|---|
|
#18+
LSVНе существуют. Есть некоторые общие (укрупненные) рекомендации. Не более.Ну как же. Тот же стандарт SQL, которому в той или иной степени соответствуют СУБД, различные xDBC, ASCII. LSVДаже такая, казалось бы более определенная вещь как ГУИ и та не имеет четких стандартов.Как раз GUI совсем не является "определенной" вещью, поэтому все и делают, как кому нравится. Хотя всякие SDI, MDI я считаю попытками унификации. Если вспомнить CAD-пакеты, офисные приложения (под Windows конечно же) то у них было очень много общего, т.е. "стандартного". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2014, 12:00 |
|
||
|
Проектирование атомарных справочников...
|
|||
|---|---|---|---|
|
#18+
Тот же стандарт SQL, которому в той или иной степени соответствуюНу да, конечно. Этих под-стандартов - вагон и тележка. Причем их существование зачастую ничем не оправдано (их можно реально сократить). Возьмите хотя бы графические стандарты. Их же эпические тыщи. Одних JPG несколько. Почти всегда можно найти графический/видео файл, кот. нормально не откроется и потребует специального драйвера/вьювера и т.д. зы: Нет ничего более примитивного чем чекбокс. Но и там умудрились наделать "несколько стандартов". :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2014, 13:08 |
|
||
|
Проектирование атомарных справочников...
|
|||
|---|---|---|---|
|
#18+
LSVЭтих под-стандартов - вагон и тележка. Причем их существование зачастую ничем не оправдано (их можно реально сократить).Ну так и предлагайте. В ANSI. Там много стандартов, которые Вы используете каждый день. LSVВозьмите хотя бы графические стандарты. Их же эпические тыщи. Одних JPG несколько. Почти всегда можно найти графический/видео файл, кот. нормально не откроется и потребует специального драйвера/вьювера и т.д. Это форматы. Не все они стандартизованы, но многие. И что? LSVзы: Нет ничего более примитивного чем чекбокс. Есть. Label например. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2014, 15:55 |
|
||
|
Проектирование атомарных справочников...
|
|||
|---|---|---|---|
|
#18+
Infernal V. RavenLSVзы: Нет ничего более примитивного чем чекбокс. Есть. Label например. Это только так кажется, что все примитивно. Команда Моно отказалась от идеи портировать wpf, прочитав только полную спецификацию в несколько десятков листов всего на один элемент(не помню точно какой). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2014, 16:32 |
|
||
|
Проектирование атомарных справочников...
|
|||
|---|---|---|---|
|
#18+
SeVaЭто только так кажется, что все примитивно. Команда Моно отказалась от идеи портировать wpf, прочитав только полную спецификацию в несколько десятков листов всего на один элемент(не помню точно какой).Я не говорил о примитивности, а даже наоборот: Как раз GUI совсем не является "определенной" вещью, поэтому все и делают, как кому нравится. Т.е. с тем что для GUI существуют проблемы стандартизации все согласны. За сим предлагаю прекратить оффтопить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2014, 17:13 |
|
||
|
Проектирование атомарных справочников...
|
|||
|---|---|---|---|
|
#18+
Infernal V. RavenТ.е. с тем что для GUI существуют проблемы стандартизации все согласныТочно такие же проблемы и в программировании. Буквально на каждом шагу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2014, 17:19 |
|
||
|
Проектирование атомарных справочников...
|
|||
|---|---|---|---|
|
#18+
Infernal V. RavenFK помешает. Читайте, описывалось ранее. Неплохо было бы, если бы вы подтвердили свои слова пуфлинком. Infernal V. RavenУдивляюсь, почему такая, по сути, простая задача требует у Вас неделю работы. Может вы что-то не так делаете? Очевидно вы недооцениваете сложность задачи. Просто добавить новую таблицу в базу - этого недостаточно. Нужно переадресовать все связи таблицах, внести изменения во всех ХП, приложениях, отчетах, подготовить боевую базу к переносу данных, и прочая прочая GoffmanТак как не существует определенных стандартов на разработку ПО, ...Infernal V. RavenВообще-то существуют. Попробуйте гугл. Опять же, пруфлинк в студию. Найдите, к примеру, такой стандарт, где указано, в каком случае следует использовать "объединенный" справочник, а в каком случае его использовать не следует. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2014, 12:11 |
|
||
|
Проектирование атомарных справочников...
|
|||
|---|---|---|---|
|
#18+
GoffmanНеплохо было бы, если бы вы подтвердили свои слова пуфлинком."ПуфЛинк" 15431877 в частности. Хотя я обычно предпочитаю не делать FK. Infernal V. RavenОчевидно вы недооцениваете сложность задачи. Просто добавить новую таблицу в базу - этого недостаточно. Нужно переадресовать все связи таблицах, внести изменения во всех ХП, приложениях, отчетах, подготовить боевую базу к переносу данных, и прочая прочаяКакие изменения вы собрались делать в ХП? Отчеты поиском проходятся. Без особых проблем и недельных посиделок. Накат на боевую базу - стандартная операция, которая выполняется каждый раз при изменениях структур и кода, т.е. ничего особенного в этом случае нет. С интеграционными схемами конечно сложнее. На моей практике вывод справочника из лукапа происходил настолько редко, что даже не припомню сколько раз это было. Возможно даже 2. Если не заниматься параноидальным сливом всех справочников в лукапы и таким же параноидальным занятием "все справочники в таблицы", то ничего страшного не происходит. GoffmanОпять же, пруфлинк в студию. Найдите, к примеру, такой стандарт, где указано, в каком случае следует использовать "объединенный" справочник, а в каком случае его использовать не следует.Разве я говорил что такой стандарт существует? Вы говорили что стандартов на разработку ПО не существует. Т.е. вообще не существует. Я с этим не согласился. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2014, 14:49 |
|
||
|
Проектирование атомарных справочников...
|
|||
|---|---|---|---|
|
#18+
GoffmanSgt.PepperНе всегда так как у Вас. Часто - это выбор между "заплатить разработчику и прождать две недели" или дать указание своему админу, что мгновенно и бесплатно... Признаться, не могу себе представить реальное применение такому подходу. Справочник ведь нужен не сам по себе, его нужно увязывать с общей моделью данных, то есть делать на него ссылочные поля в таблицах, дорабатывать под него юзерфейс, отчеты и т.д. Уж не говорю о внедрении и сопровождении "данного решения". И всем этим будет заниматься "местный админ"? Я вас умоляю... :) Не надо меня умолять. Нет понятия "ссылки" в РМД. Связи в общем случае реализуются посредством отношений. И это отношение УЖЕ создано разработчиком. Поэтому админу нужно сделать инсерт одной записи в "справочники" и наполнить этот справочник значениями, выполнив еще несколько инсертов. После чего никакой интерфейс дорабатывать не надо, поэтому "внедрение" отменяется... GoffmanSgt.PepperНу или отсутствие этого отсутствия, когда все ОЦ соблюдены. В таком случае и другие приложения могут этим пользоваться, т.к. никакой логики обработки данных на клиенте нет. Под ОЦ вы вероятно подразумеваете FK? Но ведь это мало в случае совмещенного справочника. У нас в одном справочнике лежат наименования валют и марки цемента. Кто нам помешает в поле, отвечающее за марку цемента, записать ссылку на валюту? Уж точно не FK. Получается механизмы целостности придется реализовывать на другом уровне - ХП, приложение и т.п.Под ОЦ я понимаю ОЦ. В данном случае объявив уникальность id_объекта+id_справочника я гарантирую, что для экземпляра объекта пользователь сможет указать только одно значение валюты и одно значение марки цемента. (я надеюсь, что "в одном справочнике" - это описка, Вы имели в виду "в одной таблице") Нет "поля, отвечающее за марку цемента", есть запись с маркой цемента. Непонятно почему ХП для Вас - другой уровень, но тут и ХП пока не требуются, исключительно декларативные ОЦ. Про приложение речь вообще не идет... GoffmanSgt.PepperПотенциальная проблема расширения любого справочника, со всеми прелестями изменения схемы БД на работающей системе -Тут уже платить придется, это оправданно. пожалеть 15 минут при разработке, имея шансы заработать потом недельный гемор - это по вашему оправдано? ну конечно кому как...Если справочник перестает быть классификатором вида id+name и требует введения дополнительных атрибутов или дополнительной логики, то обсуждаемый подход не годится. Я это имел в виду, а Ваш комментарий ниасилил... GoffmanSgt.PepperНапример, Кота Матроскина больше беспокоит проблема с грантами, Вас - с констрейнтами и понятностью схемы... Согласен. Так как не существует определенных стандартов на разработку ПО, разработчика волнуют больше собственные интересы, чем интересы заказчика.А заказчика интересуют собственные интересы... Что из ЭТОГО следует?... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2014, 07:47 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=38541819&tid=1540946]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
158ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
63ms |
get tp. blocked users: |
1ms |
| others: | 12ms |
| total: | 276ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...