Помогите с заказчиками физ.лица - юр.лица , в одну таблицу

[den_on_dream]

ну вы тут сошлись в бое ))

[Akina]

den_on_dream
Да вряд ли... я уже говорил - оптимальная структура зависит в значительной, если не основной, части от того, какие операции выполняются над данными. Какова процентная раскладка по ISUD, какова статичность данных, какие типы запросов и по каким атрибутам связывания и отбора превалируют, есть ли система логической архивации... да просто тупо от объёма данных и характеристик сервера по отношению к объёму. Каждая схема хранения имеет свои плюсы и минусы, и в определённых условиях плюсы могут быть решающими или незначительными, а минусы незначимыми или критичными.

[Павел Калугин]

Цитата den_on_dream @ 03.03.15, 19:24

ну вы тут сошлись в бое ))

Да какой бой, просто обсуждаем. Ибо подобные констрахции постоянно использовать приходится
Те же договора по типам. Поди разберись какой тип договора расширением какого является. А если с этими типами еще и заморочится грамотно то там и процедуры обработки наследуются, и прочая красивость возможна. И вот думай как лучше, в какую сторону "оптимизировать" в сторону быстродействия или удобства разработки или или или...

[Bas]

Цитата Павел Калугин @ 04.03.15, 13:42

в сторону быстродействия или удобства разработки или или или...

Золотую середину

[Akina]

Bas
Золотая середина - это в том редком случае, когда разработчик не только сам поддерживает продукт, но ещё и участвует в производственном процессе, который этот продукт обслуживает. Иначе как правило идёт перекос в сторону удобства именно разработки - себя любить надо, а пипл схавает.

[Павел Калугин]

Akina, ага, а еще этот разработчик должен с ростом системы стать архитектором и большой дубиной бить по рукам "новаторам".Но на практике ему этой дубиной махать не надо, потому он уходит проектировать следующую систему в другом месте. А новые разработчики перекашивают ядро то в одну то в другую сторону. И получается медленно шевелящаяся система крайне неудобная в разработке.
Сорри за флуд