|
Помощь с проектированием БД, клиенты, документы
|
|||
---|---|---|---|
#18+
17-77 и во всех формах и отчетах - не надо городить if/else/switch ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2020, 12:25 |
|
Помощь с проектированием БД, клиенты, документы
|
|||
---|---|---|---|
#18+
17-77 одно поле на все Надо вообще одну таблицу с одним полем на все сделать. Еще проще будет. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2020, 12:27 |
|
Помощь с проектированием БД, клиенты, документы
|
|||
---|---|---|---|
#18+
нашел косяк сам у себя - ИНН + unique_index физ лицо и ИП имеют одинаковый ИНН, тогда так тип (1 - юл, 2 - фл, 3 - ИП) ИНН + unique_index (тип, ИНН) ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2020, 12:34 |
|
Помощь с проектированием БД, клиенты, документы
|
|||
---|---|---|---|
#18+
fkthat Надо вообще одну таблицу с одним полем на все сделать. Еще проще будет. а это уже глупости ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2020, 12:41 |
|
Помощь с проектированием БД, клиенты, документы
|
|||
---|---|---|---|
#18+
17-77это уже глупости Нет, это всего лишь глупое утрирование уровня школоло: "меня так учили, значит это единственно правильный путь". Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2020, 13:00 |
|
Помощь с проектированием БД, клиенты, документы
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov 17-77это уже глупости Нет, это всего лишь глупое утрирование уровня школоло: "меня так учили, значит это единственно правильный путь". Я-то как раз указал сразу три разных "правильных пути", а 17-77 уперся в один единственно с его т.з. верный. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2020, 13:11 |
|
Помощь с проектированием БД, клиенты, документы
|
|||
---|---|---|---|
#18+
softwarer а мне уже давно не смешно, двойные поля и таблицы проходят сквозь все ПО: 1. в select надо будет писать два join + where fizClient.name = @search_value OR yurClient.company = @search_value 2. с сортировкой в таблице по полю name будут проблемы альтернатива делать два отдельных поля поиска, два отдельных столбца или вообще две отдельных формы списка физиков и юриков, а это уже вызывает вопросы удобства для пользователя 3. при построении списка для drop-down-list на формах редактирования надо будет join + union 4. в данных для отчетов надо будет join + coalesce(fizClient.name, yurClient.company) 5. в бизнес логике на ЯП надо будет if/else/switch или прикручивать паттерны (ага, ради одного поля) на все это надо потратить уйму времени все еще смешно? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2020, 13:17 |
|
Помощь с проектированием БД, клиенты, документы
|
|||
---|---|---|---|
#18+
тестируем дно ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2020, 13:23 |
|
Помощь с проектированием БД, клиенты, документы
|
|||
---|---|---|---|
#18+
fkthat Я-то как раз указал сразу три разных "правильных пути", а 17-77 уперся в один единственно с его т.з. верный. я обосновал свой выбор, есть конкретное рабочее решение, а не абстрактные размышления о плюсах и минусах наследования в БД это решение пока что не создает лишних проблем и ничего более сложного пока не требуется ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2020, 13:31 |
|
Помощь с проектированием БД, клиенты, документы
|
|||
---|---|---|---|
#18+
17-77 все еще смешно? Вы правы, тут скорее плакать надо. Не умеем написать view, поэтому надо везде писать coalesce и так далее в том же духе. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2020, 13:32 |
|
Помощь с проектированием БД, клиенты, документы
|
|||
---|---|---|---|
#18+
softwarer, какая разница где находится код, который все объединит? есть вариант вообще его не писать ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2020, 13:43 |
|
Помощь с проектированием БД, клиенты, документы
|
|||
---|---|---|---|
#18+
и вьюха не избавит от того, что придется писать две формы для создания/редактирования ФЛ/ЮЛ или применять if/else/switch, чтобы скрыть поля ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2020, 13:58 |
|
Помощь с проектированием БД, клиенты, документы
|
|||
---|---|---|---|
#18+
Vladimir_84_, Владимир, Вам правильно подсказывают по поводу единой таблицы клиентов, ведь клиент может быть к примеру и ФЛ и ИП, даже встречалось, что одно ОГРН было у двух предприятий, одно было уже давно закрытым. Вижу такой вариант - создайте одну общую таблицу клиентов, справочник атрибутов (это м.б. ИНН, информация по документу, месту регистрации, юрид.адрес, ОГРН, КПП, СНИЛС, дата регистрации ЮЛ, бенифициар, рез/нерез, т.е. для каждого типа клиента - гибкий набор атрибутов, подключается оператором по мере необходимости ) и таблицу, где будут хранится заполненные оператором атрибуты клиента. Таблица для ведения дел - немер дела, далее привязываются клиенты из общей таблицы Клиентов, указывается его тип - истец/ответчик, привязываются доверенности, карточки образцов подписей, печатей и прочие основные доки. И возможно отдельная таблица с материалами дела. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2020, 14:03 |
|
Помощь с проектированием БД, клиенты, документы
|
|||
---|---|---|---|
#18+
17-77 есть конкретное рабочее решение Отхожее место в виде ямы на улице это тоже "конкретное рабочее решение", когда про другие опции не знаешь. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2020, 14:11 |
|
Помощь с проектированием БД, клиенты, документы
|
|||
---|---|---|---|
#18+
17-77 softwarer, какая разница где находится код, который все объединит? есть вариант вообще его не писать Я же предложил уже вариант - одна таблица с одним большим полем. И одна форма с одним большим текстовым полем для ввода. Минимум затрат на разработку. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2020, 14:14 |
|
Помощь с проектированием БД, клиенты, документы
|
|||
---|---|---|---|
#18+
fkthatодна таблица с одним большим полем. Вообще-то с двумя, поскольку широкий список неудобен, но таки да, такой вариант тоже уместен. И я его предлагал выше гораздо раньше. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2020, 14:17 |
|
Помощь с проектированием БД, клиенты, документы
|
|||
---|---|---|---|
#18+
fkthat, да сколько уже можно, все три подхода - это две таблицы/два поля, на текущем этапе это только создает проблемы, а не решает их "знать про них" и "применять к месту" разные вещи и мое решение с легкостью конвертируется в tph и немного труднее в tpt/tpc, если это потребуется в будущем ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2020, 14:21 |
|
Помощь с проектированием БД, клиенты, документы
|
|||
---|---|---|---|
#18+
17-77 какая разница где находится код, который все объединит? В данном случае эта разница просто показывает, что стенания про "куча лишней трудоёмкости, надо джойны в каждом комбобоксе писать" идёт исключительно от неумения пользоваться базовыми инструментами. Равно как - я вроде уже говорил - об этом же говорят высказывания о том, что количество таблиц связано с количеством форм. Что же касается этих решений, то основная практическая разница между ними в том, что в реляционных базах хранить мух отдельно от котлет, при необходимости собирая их, заметно удобнее, чем хранить вместе, при необходимости разбирая и потом заново собирая другим нужным способом. Решение с "одной общей таблицей" хуже расширяется, поэтому при близкой трудоёмкости его имеет смысл выбирать только тогда, когда есть твёрдая уверенность в том, что постановка задачи близка к окончательной и существенных доработок не будет. В противном случае Ваша экономия на спичках обернётся выбрасыванием и полным переписыванием как наиболее рациональным методом доработки решения под новые требования. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2020, 14:33 |
|
Помощь с проектированием БД, клиенты, документы
|
|||
---|---|---|---|
#18+
fkthat Я же предложил уже вариант - одна таблица с одним большим полем. И одна форма с одним большим текстовым полем для ввода. Минимум затрат на разработку. есть баланс между говнокодом, удобством и здравым смыслом - в этом решении баланс стремится к нулю решение с единым полем наименование/фио - это не по канонам, но отсекает половину срока разработки, ты реально хочешь угробить в два раза больше времени лишь бы следовать идолу? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2020, 14:37 |
|
Помощь с проектированием БД, клиенты, документы
|
|||
---|---|---|---|
#18+
17-77 все три подхода - это две таблицы/два поля Что за ересь. TPH - "table per hierarhy", TPC - "table per concrete type", TPT - "table per type". "В одну таблицу" из них это только TPH. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2020, 14:47 |
|
Помощь с проектированием БД, клиенты, документы
|
|||
---|---|---|---|
#18+
17-77 решение с единым полем наименование/фио - это не по канонам, но отсекает половину срока разработки У тебя создание одного дополнительного поля в БД занимает столько же времени как вся остальная разработка? Ты его что, прямо в файлах базы бинарным редактором создаешь? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2020, 14:50 |
|
Помощь с проектированием БД, клиенты, документы
|
|||
---|---|---|---|
#18+
softwarer идёт исключительно от неумения пользоваться базовыми инструментами мне знакомы view, но я не хочу внедрять лишний компонент, когда он только что и делает - это решает выдуманные проблемы не забыть бы потом его доработать softwarer Решение с "одной общей таблицей" хуже расширяется пожалуй да, но никто не мешает в моем решении добавить рядом еще три таблицы ЮЛ с егрюл, ИП с огрнип и ФЛ с паспортом, когда они понадобятся, и волки сыты и овцы целы. старое ломать не придеться. fkthat "В одну таблицу" из них это только TPH. ну да, но этот вариант по канону подразумевает два поля - наименование для ЮЛ и фио для ФЛ, два поля - привет вьюха/if/else/switch/coalesce fkthat У тебя создание одного дополнительного поля в БД занимает столько же времени как вся остальная разработка? Ты его что, прямо в файлах базы бинарным редактором создаешь? а пробрасывать его везде в приложении кто будет? пушкин? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2020, 16:34 |
|
Помощь с проектированием БД, клиенты, документы
|
|||
---|---|---|---|
#18+
17-77 а пробрасывать его везде в приложении кто будет? пушкин? метаданные ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2020, 16:59 |
|
Помощь с проектированием БД, клиенты, документы
|
|||
---|---|---|---|
#18+
17-77 пожалуй да, но никто не мешает в моем решении добавить рядом еще три таблицы Веселье в Вашем решении начнётся, как только потребуется кинуть внешний ключ на юрика или разобрать "наименование" физика отдельно на фамилию, имя и отчество. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2020, 17:17 |
|
Помощь с проектированием БД, клиенты, документы
|
|||
---|---|---|---|
#18+
17-77 ну да, но этот вариант по канону подразумевает два поля - наименование для ЮЛ и фио для ФЛ На самом деле три, т.к. еще нужен дискриминатор. 17-77 привет вьюха/if/else/switch/coalesce Если на клиенте используется ОРМ, то вообще ничего не нужно - давно уже все ОРМы прекрасно мепят подтипы в РБД на наследование классов в коде. Впрочем ладно, твоя взяла, говнокодь свой говнокод как тебе удобней, храни телефоны в полях для e-mail, а вес товара в полях для цены, все равно не мне с этим потом долбаться. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2020, 17:20 |
|
|
start [/forum/topic.php?fid=32&msg=39979885&tid=1539843]: |
0ms |
get settings: |
7ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
28ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
58ms |
get tp. blocked users: |
1ms |
others: | 246ms |
total: | 368ms |
0 / 0 |