J
тогда на каждое поле отдельную таблицу и для компании указывать идентификаторы для тех полей, которые используются - первое, что приходит в голову
Отдельную таблицу? А градация, какая межд ними будет, к примеру companies_1, companies_2?
Size: a a a
2021 March 30
ВС
про архитектурное решение это очень спорно :) так называемый говнокод может работать быстрее и стабильнее супер пупер фреймвока, а плюс последнего в виде толпы дешевых разработчиков для поддержки не всегда очевиден в таком случае. Но в рамках корпоративной культуры даже помыслить такое страшно)
Вы спросили, как обидеть программиста - я назвал с ходу первый пример, который не должен оставить равнодушным никого, кто считает себя программистом. Архитектурное решение - это не про фреймворки вообще. И даже не про ЯП.
A
Вы спросили, как обидеть программиста - я назвал с ходу первый пример, который не должен оставить равнодушным никого, кто считает себя программистом. Архитектурное решение - это не про фреймворки вообще. И даже не про ЯП.
ну дэк я и говорю, это критично для коллектива, в коробке уже никому не интересно, какая архитектура, интересно как работает
J
я не говорю, что это лучшее решение, но так будет работать, причем очень быстро
ну... не знаю даже, это единственное решение?
J
если все поля известны, т.е. каждая компания ими обладает , просто у некоторых какие-то могут быть не заполнены .. зачем их разносить по разным таблицам ?
Минимум 3 вида, в каждом виде > 6 уникальных полей
ВС
ну дэк я и говорю, это критично для коллектива, в коробке уже никому не интересно, какая архитектура, интересно как работает
При чём тут интересно или не интересно. Разработанная архитектура сопровождает проект всё его время существования. Это как если бы всем было наплевать, что у вас есть особенности правой конечности, которые доставляют неудобства при её использовании, например. Но вы ежедневно с этим сталкиваетесь, несмотря на то, что всем наплевать и несмотря на то, что все могут взаимодействовать с вами, несмотря на этот недостаток.
J
все в одну, тоже не вариант
ВС
Так и разработчики, поддерживая проект, будут работать с архитектурой всё это время.
J
есть компании, условно 1-100
есть поля, компоновка которых для каждой компанит неизвестна заранее, но известны при этом все типы полей
есть поля, компоновка которых для каждой компанит неизвестна заранее, но известны при этом все типы полей
Ну, в принципе да
A
Так и разработчики, поддерживая проект, будут работать с архитектурой всё это время.
ну так тогда нет никаких проблем не давайте джуну или сеньору делать архитектуру и нет проблемв
V
все в одну, тоже не вариант
во первых не известно что за поля .. а во вторых никто не говорил что все в одну ... но разносить каждое в отдельную таблицу такое себе