|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
У нас заведена практика на каждое поле выбора заводить отдельный справочник, соответствующий энаму на бэке. У одной и той же сущности может быть несколько полей для статуса - статус анкетирования, статус аттестации и т.д. И для каждого такого статуса - отдельная таблица-справочник. Большая часть этих справочников вообще никогда не используется, но они помогают быстро сопоставить базу и фронт при возникновении каких-либо проблем. Но вот заказчик просит завести 1 справочник примерно такого вида Код: sql 1. 2. 3. 4. 5.
Куда собирается класть разные статусы разных сущностей. Слабая аргументация "пусть пока так будет" меня в восторг не приводит. Так как с базой работают много разработчиков, то наличие большого количества справочников препятствует лишней индексации таблиц. Мало у кого поднимется рука построить индекс по полю, где всего 3 разных значения (судя по связанному справочнику). Но вот по ссылке на справочник из 200 строк уже могут. Какого-то отчета, где требовалось бы вывести все статусы для разных сущностей у нас нет, и вряд ли такое понадобится. Но может я чего не вижу, и у большого справочника статусов есть свои плюсы? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2020, 12:26 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
Шамиль Фаридович, У нас есть один проект, в котором разработчики бэка принципиально не делают enum-ы в БД. По этому для отчетов сделана одна большая таблица (такая какую хочет ваш заказчик), которую мы поддерживаем сами. И есть другой проект, в котором несколько сотен маленьких таблиц. Не испытываем ни каких проблем ни там, ни там. Удовольствий, в прочем, тоже нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2020, 14:11 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
Шамиль Фаридович Мало у кого поднимется рука построить индекс по полю, где всего 3 разных значения (судя по связанному справочнику). Но вот по ссылке на справочник из 200 строк уже могут. А какая разница, даже если там не 200, а 200 тыс. значений, если в отдельно взятой таблице все равно будут встречаться только 3 из них. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2020, 15:00 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
внешние ключи как-то подвязывать собираетесь? если нет, то в принципе пофиг ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2020, 18:07 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
andreymx, Да, внешние ключи в любом случае будут, 99% все ФК будут некаскадными. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2020, 21:33 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
Шамиль Фаридович andreymx, Да, внешние ключи в любом случае будут, 99% все ФК будут некаскадными. звук: твердый твердость: голубой зато все параметры в справочнике :) ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2020, 22:47 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
andreymx, Узнал аргумент автора идеи с большим справочником: увеличивается скорость разработки вроде как за счет уменьшения количества энамов. А вот лид с бека говорит, что это небольшое ускорение с лихвой компенсируется сложностью поддержки этого большого энама, ибо сами разработчики иногда путают EntityType. И да, твердый цвет уже встречался. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2020, 09:41 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
на один справочник проще сделать общее приложение чем лепить 200 хотя если они однотипные, то нормальному разрабу не сильно сложнее сделать общую форму для всех 200 ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2020, 10:34 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
Шамиль Фаридович ибо сами разработчики иногда путают EntityType Для 200 отдельных предлагаю сделать сквозной сиквенс, и FK тогда точно ничего не перепутается ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2020, 10:42 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
andreymx Для 200 отдельных предлагаю сделать сквозной сиквенс, и FK тогда точно ничего не перепутается А зачем сквозной сиквенс? Ведь каждый FK будет на свою таблицу-справочник. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2020, 12:44 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
Шамиль Фаридович andreymx, Узнал аргумент автора идеи с большим справочником: увеличивается скорость разработки вроде как за счет уменьшения количества энамов. А вот лид с бека говорит, что это небольшое ускорение с лихвой компенсируется сложностью поддержки этого большого энама, ибо сами разработчики иногда путают EntityType. И да, твердый цвет уже встречался. В случае стправочников в БД у них на беке enum-ов вообще быть не должно. Или же они собираются при каждом изменении справочника в БД вносить изменения в код и все пересобирать. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2020, 12:52 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
Шамиль Фаридович, вам же потом каждый раз придется разворачивать эту таблицу... в один момент количество записей в такой структуре станет довольно велико и расходы на разворачивание повысятся, затем последует отказ от такого вида хранения и переделка всего, что наколбасили за это время - а это будут существенные расходы ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2020, 14:15 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
Обсуждалось в проектировании. Аргумент ЗА только один - это круто, модно, молодежно. Я художник, я так вижу. Остальная экономиня - натягивание совы на глобус. Поскольку это вопрос ВЕРЫ - переубедить рациональными аргументами невозможно. Аргументы против - права на все справочники будут одинаковыми, вместо N таблиц-справочников легко появляются N вьюх (ибо выпадающие поля надо делать) Сложнее добавить поле в отдельный справочник, (не влезает в прокрустово ложе универсала) твердый цвет уже упомянуто. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2020, 17:51 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
SERG1257, Права можно реализовать с помощью безопасности на уровне строк. Это конечно добавит новые тормоза, но вполне возможно так сделать. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2020, 19:23 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
Шамиль Фаридович, авторId EntityTypeId Kind Name Должно быть два справочника для такой задачи: EntityType (ID, description, Enabled, SoOn) EntityTypeKind (EntityTypeID, ID, Name, SoOn) ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2020, 19:27 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
Шамиль Фаридович, щас модно всю справочно-конфигурацию в одном json файле хранить. и что такое справочник? чем он отличается он не справочника? список сотрудников это справочник? а список проектов над какими они работают тоже? и чем список статусов отличается в этом плане? есть только сущности (entity) и отношения между ними (association) и ничего более. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2020, 19:51 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
Relic Hunter и что такое справочник? Под "справочником" обычно подразумевают таблицу, единственная цель которой это просто перечисление допустимых значений какого-либо поля из другой таблицы. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2020, 20:21 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
нет. fkthat Relic Hunter и что такое справочник? Под "справочником" обычно подразумевают таблицу, единственная цель которой это просто перечисление допустимых значений какого-либо поля из другой таблицы. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2020, 21:49 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
не совсем понятно, почему уперлись в "одну большую таблицу". Что мешает сделать несколько "средних"? :) Разбивая по типам, содержимому и необходимостям. А вот это: "Большая часть этих справочников вообще никогда не используется" -настораживает, обычно означает, что проектирование хромает. Ибо: "не стоит плодить сущности сверх необходимого" :) ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2020, 22:19 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
Критик Права можно реализовать с помощью безопасности на уровне строк. Это конечно добавит новые тормоза, но вполне возможно так сделать. Нет никаких сомнений, что они это сделают глючнее, тормознутее, чем специалисты вендоров СУБД, работать с этим будет сложнее, что на это нельзя будет найти специалиста, и главное, зачем тратить деньги на то, что уже есть? Расходы будут такими, что топовые версии Оракл с Сиквелом покажутся практически бесплатными. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2020, 23:28 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
fkthat Relic Hunter и что такое справочник? Под "справочником" обычно подразумевают таблицу, единственная цель которой это просто перечисление допустимых значений какого-либо поля из другой таблицы. Именно так. Причем чаще всего справочник очень статичен. SERG1257Поскольку это вопрос ВЕРЫ - переубедить рациональными аргументами невозможно. Вот это уже печально. Вообще за 2 дня не увидел ни одного довода за большой справочник. Зато кучу советов, как его лучше реализовать, в том числе и для бэка. Там крутые ребята, не беспокойтесь:) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2020, 01:11 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
Довод "за" только один - если запихнуть в одну таблицу все справочники, то проект в SSDT не будет тормозить ) ps если в проекте десятки тысяч объектов, то он валидируется весьма неспешно, но даже это не стоит тех трудностей, которые вы себе обеспечите применением EAV-модели - вот представьте, что вам нужно выпилить из системы какой-нибудь функционал, тогда вам нужно будет не только удалять таблицы, но и выборочно избавляться от данных в подобном справочнике, короче, геморрой будет ) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2020, 01:19 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
Relic Hunter список сотрудников это справочник? а список проектов над какими они работают тоже? Если по теме, то иногда проще не париться. Ну, хочет заказчик сделать так, ты привел доводы, что лучше делать иначе. Он не согласился. Значит либо доводы были недостаточными и в следующий раз нужно быть более убедительным. Либо заказчик СЗБ, его предупредили о проблемах, он принял на себя эту ответственность. Или может ты чего-то не знаешь, может у них сто других проектов уже сделаны по этой схеме и им так действительно проще. Если весь проект такой, что каждую фигню нужно с кем-то согласовывать, всё делается плохо и сложно, и это годами не меняется, то проще сменить работу. Я реально сталкивался с проектами, где какой-то школьник на архитекторе спроектировал и базу данных, и пользовательский интерфейс. И заказчик спрашивает почему целых 2 недели заложено на реализацию модуля, мы же вам всё уже расписали, посадите программиста, он за пару дней всё сделает. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2020, 09:38 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
Шамиль Фаридович, А какие ты хочешь доводы? Для доводов нужно знать проект и условия для его разработки и применения. Для этого есть спецлюди, которые за определенное время и неплохой гонорар все это проанализируют и выдадут совет. А здесь ... Ну "помахали" тебе руками... Легче стало? :) Даже если у вас все сделано через жопу, но вы к этому привыкли и это вам не сильно мешает - ну, продолжайте... Т.к. большие изменения лучше убирать при кардинальной смене проекта. PS. Вот я сейчас работаю с базой, где, чтобы вытащить значение, нужно пройти через 8 немаленьких таблиц, причем, весьма нетривиальным способом и ломаю голову, как бы это все ускорить. Периодически вспоминая разработчиков тихим ласковым словом :) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2020, 09:42 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
Доводы в пользу 1-го большого справочника: 1. Для создания нового справочника нужно всего лишь вставить неск. записей. Не нужны права на создание таблицы . 2. Удаление лишних справочников - см. п.1. 3. Список таблиц в проекте будет кратким, а не с многими сотнями микротаблиц. 4. Вычитку нужного значения из "единого" справочника можно сделать простым одинаковым подзапросом или одной функцией. 5. Единый и простой гуи-интерфейс. На избитый вопрос "а как же ссылочная целостность ?" встречный вопрос "Вам известна хоть одна известная ERP-система, где СЦ уровня СУБД используется ?" Недостатки: 1. Сложно делать справочники, если они неодинаковые по структуре, н-р с дополнительными ссылками или инф. полями. Хотя эта проблема частично решается тем же EAV. 2. Безопасность ниже, чем в случае отдельных таблиц. Хотя и тут можно применить ряд мер, усложняющих несанкц. доступ. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2020, 11:25 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
L_argo Доводы в пользу 1-го большого справочника: 1. Для создания нового справочника нужно всего лишь вставить неск. записей. Не нужны права на создание таблицы . 2. Удаление лишних справочников - см. п.1. 3. Список таблиц в проекте будет кратким, а не с многими сотнями микротаблиц. 4. Вычитку нужного значения из "единого" справочника можно сделать простым одинаковым подзапросом или одной функцией. 5. Единый и простой гуи-интерфейс. На избитый вопрос "а как же ссылочная целостность ?" встречный вопрос "Вам известна хоть одна известная ERP-система, где СЦ уровня СУБД используется ?" Недостатки: 1. Сложно делать справочники, если они неодинаковые по структуре, н-р с дополнительными ссылками или инф. полями. Хотя эта проблема частично решается тем же EAV. 2. Безопасность ниже, чем в случае отдельных таблиц. Хотя и тут можно применить ряд мер, усложняющих несанкц. доступ. Перевожу: 1) Можно говнокодить. 2) Можно говнокодить. 3) Боюсь большого кол-ва таблиц. 4) Не умею писать сложные sql-запросы. 5) Единственный, наверное, аргумент ЗА. И то, не факт, что так будет. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2020, 16:14 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
Megabyte Перевожу: 1) Можно говнокодить. 2) Можно говнокодить. 3) Боюсь большого кол-ва таблиц. 4) Не умею писать сложные sql-запросы. 5) Единственный, наверное, аргумент ЗА. И то, не факт, что так будет. 1 и 2 "Можно говнокодить" касается абсолютно любого решения. 3. Зачем нужно 350 таблиц, если можно иметь 50 ? 4. Зачем писать сложный запрос, если можно написать простой ? зы: Говнокод - код написанный другим человеком (с) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2020, 17:05 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
L_argo 3. Зачем нужно 350 таблиц, если можно иметь 50 ? Вот только станет ли от этого легче? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2020, 18:01 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
L_argo Зачем нужно 350 таблиц, если можно иметь 50 ? Да можно вообще одну. У такой таблицы в реляционной теории даже название какое-то есть, только я его не помню. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2020, 18:26 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
Как видно доводы универсального справочника пересекаются с доводами любителей EAV. Но в отличие от EAV, универсальный справочник не влияет на производительность. > "Можно говнокодить" касается абсолютно любого решения Давайте предположим что программист облажался - пишет в справочник "MyTable", а читает из "My Table" И вместо явного эксепшена получаем скрытый баг. Хотя о чем это я. Тормоза придумали трусы, а РАЗРАБОТЧИКИ не ошибаются. >встречный вопрос "Вам известна хоть одна известная ERP-система, где СЦ уровня СУБД используется ?" В лучших домах ЛондОна и Парижа инструментом не пользуются значит и мы не будем. Шамиль Фаридович, обратите внимание на аргументы - рационального в них мало, еще чуть-чуть и будет переход на личности. Это вопрос веры - упирать надо на другие аргументы: Кодд не одобряет смешение метаданных (тип справочника) в данных >Вы удивитесь, но ВСЕ таблицы ВСЕЙ базы можно хранить в ОДНОМ поле ОДНОЙ таблицы! Можно но по канону три таблицы: E, A, V ... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2020, 18:27 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
L_argo Доводы в пользу 1-го большого справочника: Давайте я лучше приведу такие же плюсы использования одной переменной и одного объекта в программе, написанной на Java или Дельфи? А то достало уже множество переменных, дурацких классов, пусть всё будет по современному: весь код в одной процедуре с goto, и вместо переменных один массив из строк, в каждый элемент которого можно будет класть то, что надо в данный момент! Какой я молодец, видите, никогда на Джаве и Дельфи не программировал, и сразу всё понял, как правильно делать! Всё упростил! ... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2020, 19:24 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
Ares_ekb Relic Hunter список сотрудников это справочник? а список проектов над какими они работают тоже? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2020, 19:32 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
iap Вы удивитесь, но ВСЕ таблицы ВСЕЙ базы можно хранить в ОДНОМ поле ОДНОЙ таблицы! Контр-аргументы свелись к шуткам-прибауткам. И что-то никто не назвал ERP-систем, в кот. соблюдается СЦ и все каноны РСУБД. Видимо местные знатоки считают себя выше всех разработчиков ERP-систем... ... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2020, 19:52 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
alexeyvg Давайте я лучше приведу такие же плюсы использования одной переменной и одного объекта в программе, написанной на Java или Дельфи? А то достало уже множество переменных, дурацких классов, пусть всё будет по современному: весь код в одной процедуре с goto, и вместо переменных один массив из строк, в каждый элемент которого можно будет класть то, что надо в данный момент! я подозреваю, что однажды так и будет, осталось главное - придумать модное название для вашей архитектуры ) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2020, 21:47 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
L_argo Контр-аргументы свелись к шуткам-прибауткам. Я вам привёл пример, пообсуждайте его в "Дельфи", серьёзных ответов будет меньше, чем здесь. L_argo И что-то никто не назвал ERP-систем, в кот. соблюдается СЦ и все каноны РСУБД. Мы же тут обсуждаем не "все каноны" и "СЦ", а конкретный вопрос, "использование для всех справочников одной таблицы". Ни в одной ЕРП такого, конечно, нет. И местные знатоки, считая себя на уровне разработчиков крутых ЕРП, делают так же. И EAV местные знатоки считают нужным использовать, временами, только не как "вся база в трёх универсальных таблицах", или "универсальная объектная модель", а так же, как это делается в серьёзных системах, для доп атрибутов. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.11.2020, 20:55 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
Есть более серьёзный вопрос - куда поместить информацию о версии программы? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.11.2020, 22:34 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
Я сталкивался с подходом большой таблицы возможен микс как на текущем проекте мелочевка засунута в refdata большие справочники отдельно 1) проблема в том что когда надо ввести новое поле в большую таблицу - либо для всех добавлять либо выносить справочник отдельно 2) когда вешали поверх справончиков QlickView пришлось делать вью для каждого спраовчника из большой таблицы (потому что Клик связи выставлял по именам полей ) Но в целом микс возможен ибо 1000 мелких справочников тоже НЕ сильно удобно. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2020, 16:24 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
автора конкретный вопрос, "использование для всех справочников одной таблицы".Зачем передергивать ? Кто говорил про все справочники ? Речь шла о однотипных минисправочниках из 2-3 полей. В большой системе их могут быть сотни. Н-р в 1С это называется перечисления. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2020, 17:45 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
alexeyvg Мы же тут обсуждаем не "все каноны" и "СЦ", а конкретный вопрос, "использование для всех справочников одной таблицы". Ни в одной ЕРП такого, конечно, нет. Сейчас может и нет, а вот в АИС ТПС НК "ЮКОС" именно так и было: одна таблица SR_REFERENCE ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2020, 18:05 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
L_argo Речь шла о однотипных минисправочниках из 2-3 полей. В большой системе их могут быть сотни. Да, именно для таких справочников, где код, наименование и описание. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2020, 18:07 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
>ибо 1000 мелких справочников тоже НЕ сильно удобно. Чем, черт побери, 1000 вьюшек удобнее 1000 мелких таблиц. Где выгода? Тем более у ТС, и в реальности это ДЕСЯТКИ (даже не сотни) справочников. Они легко скриптуются. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2020, 18:37 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
Да, речь об однотипных справочниках, причем желательно не только по форме, но и по содержанию (цвет в статусы не запихивать). Расскажу как было на другом проекте. Для каждого поля выбора делался отдельный справочник в базе с FK на него + энам в бэке. Таким образом, любое изменение необходимо было делать сразу в 2х местах: база и бэк. Это время от времени порождало ошибки несогласованности и, в целом, было избыточным. Вполне достаточно хранить такие вещи в одном месте, база к данным ближе, и всегда есть какие-то отчеты с использованием поля Name какого-то количества справочников. Если использовать модель со справочником для каждого поля выбора, то бэку придется писать новый метод для заполнения каждого такого выпадающего списка. Я попросил бэк показать код, работающий с 1 большим справочником, и мне понравилось: небольшой DAL-класс, всего пару методов, и нет необходимости согласований с базой. Нужно лишь дождаться, пока базист закроет свой тикет. Это и правда увеличивает скорость разработки , пусть и сохраняет все описанные в этом топике недостатки. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2020, 20:02 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
L_argo автора конкретный вопрос, "использование для всех справочников одной таблицы". Кто говорил про все справочники ? Речь шла о однотипных минисправочниках из 2-3 полей. В большой системе их могут быть сотни. Н-р в 1С это называется перечисления.Ну, из поста ТС точно непонятно, что имеется в виду. И в 1С, уверен, нельзя будет занести в поле "цвет" значение "твёрдый". В 1С это не "одна табличка", а некая система "перечисления", которая устанавливает перечень допустимых значений и т.п. С кучей метаданных, интерфейсными формами, отчётами для администратора и т.д. А сделано так потому, что в 1С свой язык, по сути, своя РСУБД, которая есть надстройка над ядерной РСУБД. То есть в системе уровня SAP, 1C, SharePoint, MS, Excxange такое можно понять. Притом не для всех справочников, по критерию "в которых мало записей", а в определённых бизнес-справочниках, что тоже большая разница. А вот в системе ,в которой 30-100 справочников, нет своего ЯП, своего дизайнера, которая не является "конструктором", всего этого не надо. Либо лишнее усложнение и удорожание, либо сделанная "для галочки" одна "таблица-справочник", которая, кроме удорожания кода, ничего не принесёт) ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2020, 22:18 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
Шамиль Фаридович то бэку придется писать новый метод для заполнения каждого такого выпадающего списка. ... Это и правда увеличивает скорость разработки , Проблема в данном случае не в недостатках отдельных справочников, а в программной архитектуре (API) бэка. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2020, 22:22 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
авторЕсли беку писать новый метод для заполнения каждого такого выпадающего списка в случае одного справочника, то никакой экономии не будет.А зачем писать, если можно не писать ? Заполнение и импорт всех справочников происходит в одной форме, которая принимает в качестве вх.параметра лишь имя конкретного справочника. Причем это прекрасно ложится на нативный SQL. Именно в этом и фишка - сделать один несложный код для всех. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2020, 09:56 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
L_argo авторЕсли беку писать новый метод для заполнения каждого такого выпадающего списка в случае одного справочника, то никакой экономии не будет. Именно в этом и фишка - сделать один несложный код для всех. А кто мешает сделать один метод, но параметризированный, где параметром выступает имя таблицы-справочника(раз уж у вас справочники одной формы)? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2020, 13:31 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
Шамиль ФаридовичЭто и правда увеличивает скорость разработки, пусть и сохраняет все описанные в этом топике недостатки.Вот, честный ответ: быстро, дешево и сердито. Я знаю другие программисткие приемы увеличивающие скорость разработки. Правда другие программисты называют их говноко техническим долгом, проводят всякие коде-ревью и рефакторинги, все ради того парня, который будет это поддерживать. В данном случае тот парень он не ваш, не разработчик. Пусть в случае универсального справочника вероятность косяков небольшая (по сравнению с логическим продолжением этого подхода в EAV), но зачем плодить технический долг, срезать углы (уголки даже) с вероятностью переделывать. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2020, 17:18 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
L_argo авторЕсли беку писать новый метод для заполнения каждого такого выпадающего списка в случае одного справочника, то никакой экономии не будет. Именно в этом и фишка - сделать один несложный код для всех.А зачем каждый раз писать новый метод, для справочников в отдельных таблицах? Разные таблицы, или одна - это просто чуть разные метаданные, не более. Сервер хранит имя таблицы, или вы сами - не надо, что бы от этого зависело количество методов в классах. SERG1257 Шамиль ФаридовичЭто и правда увеличивает скорость разработки, пусть и сохраняет все описанные в этом топике недостатки. Ребята пишут горы безумного ненужного кода на каждую новую таблицу, ибо "так надо", "все так делают". Но если таблица будет виртуальная. самопальная, то почему то уже "так не надо", потому то уже не нужно делать на каждую строку большого справочника свой метод. То есть если используется серверные метаданные sys.tables, то по фэн-шую надо сделать в дата-слое класс для каждой таблички, а вот если своя васяпупкин.tables, то почему то вдруг не надо, по тому же фен-шую. Очень странно. Шамиль Фаридович Если использовать модель со справочником для каждого поля выбора, то бэку придется писать новый метод для заполнения каждого такого выпадающего списка. Нужно для справочников вида выпадающий список делать один класс, и передавать в него имя таблицы. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2020, 17:45 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
На бэке (REST API) все справочники маленькие отдельные таблички, но возникли проблемы с их получением на фронте (Angular.js). Все вызовы с фронта - асинхронные. Это приводило к тому, что справочники загружались рандомно и некоторые не успевали приехать к открытию страниц. Было принято решение передавать все справочники одним методом на фронт, а фронт уже их сортировал куда нужно. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2020, 19:20 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
Relic Hunter На бэке (REST API) все справочники маленькие отдельные таблички, но возникли проблемы с их получением на фронте (Angular.js). Все вызовы с фронта - асинхронные. Это приводило к тому, что справочники загружались рандомно и некоторые не успевали приехать к открытию страниц. Было принято решение передавать все справочники одним методом на фронт, а фронт уже их сортировал куда нужно. Мы же не говорим про "простокод", когда на таблицы автоматом генерятся дата-классы, а запросы сам составляет фреймфорк? Есть модель БД, есть архитектура, модель, сервера приложений, и есть модель клиентского приложения, и это три разные модели, а не одна. Притом для одной базы может быть несколько серверов приложений, и ещё больше приложений, да и баз, собственно, тоже может быть много, в общем случае. И ничего не мешает иметь 50 таблиц-справочников, некую структуру классов в сервере приложений, с блэк-джеком и кэшированием, и один компактный массив для кода страницы (притом для разных страниц массивы разные, только то, что будет использовано на странице) ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2020, 23:56 |
|
60 справочников по 3 строки или один на 200
|
|||
---|---|---|---|
#18+
Извиняюсь. Но Штирлица неудержимо рвало на Родину. Центавр Омега Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48.
... |
|||
:
Нравится:
Не нравится:
|
|||
05.12.2020, 23:47 |
|
|
start [/forum/topic.php?all=1&fid=46&tid=1685331]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
58ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
86ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 201ms |
0 / 0 |