|
Помощь с проектированием БД, клиенты, документы
|
||
|---|---|---|
Участник
Откуда: Москва
Сообщения: 1 106 |
||
| 13.07.2020, 11:46 |
|
|
|
|
|
Помощь с проектированием БД, клиенты, документы
|
|||
|---|---|---|---|
|
#18+
Здравствуйте. Пишу GUI приложение, типа "Помощник юриста", с использованием SQLite. БД никогда не занимался, этому никогда не обучался. Поэтому не знаю, правильно ли всё делаю. По сути приложения. Есть два типа клиентов - физ. и юр. лицо. Я их выделил в две отдельные таблицы и связал с общей таблицей (id клиента и его категория). У клиента есть дела, я общую таблицу клиентов связал с таблицей Дела по id клиента. Дальше не знаю... Могут быть документы, аудио, фото, текст. При этом могут быть три владельца этих документов - документ по делу, документ клиента, документ пользователя. Как бы это все правильно связать то? Просят с меня схему, ну нарисовал её по быстрому в программе Valentina Studio, для наглядности, не все поля прописал. Но понимаю, что не правильно наверное. Вот, вообщем-то прошу совета, как это все разделить то и связать грамотно. Запросы будут строиться исходя из нажатия кнопок пользователем, так что проблем с отнесением к категориям владельца или типа документа не должно быть. Спасибо, сильно не пинайте ). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2020, 16:51 |
|
||
|
Помощь с проектированием БД, клиенты, документы
|
|||
|---|---|---|---|
|
#18+
Vladimir_84_Могут быть документы, аудио, фото, текст. При этом могут быть три владельца этих документов - документ по делу, документ клиента, документ пользователя. Как бы это все правильно связать то? Тут надо смотреть на сущность этих документов и операции, которые с ними могут быть произведены в рамках бизнес-логики. Но скорее всего таки правильнее будет создать три отдельные таблицы документов, привязанные к делу, клиенту и пользователю соответственно. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2020, 17:06 |
|
||
|
Помощь с проектированием БД, клиенты, документы
|
|||
|---|---|---|---|
|
#18+
Идея такая, что пользователь может с внешнего носителя загрузить в БД файл (или фото со сканера). Это может быть допустим фото судебного дела (по конкретному делу из таблицы Дело), или может скан паспорта клиента (т.е. нет привязки к делу, только к клиенту) или документ лично пользователя (допустим аудио с семинара адвокатов). А приложение дает возможность фильтрации по клиенту, по делу, открытия этих документов прямо из окна приложения, поиска по дате добавления и т.д. А три отдельные таблицы это что имелось в виду? Умотался уже, не совсем соображу. Вообще в принципе от того, что есть сейчас можно отталкиваться или совсем ерунда получается? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2020, 17:20 |
|
||
|
Помощь с проектированием БД, клиенты, документы
|
|||
|---|---|---|---|
|
#18+
Vladimir_84_А три отдельные таблицы это что имелось в виду? create table "документы по делу" ... create table "документы клиента" ... create table "документы пользователя" ... Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2020, 17:25 |
|
||
|
Помощь с проектированием БД, клиенты, документы
|
|||
|---|---|---|---|
|
#18+
А, спасибо. Но чет не догоняю немного. Вот у меня есть таблица clientDocs - ну вроде документы клиента и есть (id клиента + id документа) и casesDocs(id дела + id документа). id документа все уникальные и берутся из общей таблицы Documents... То есть эта промежуточная общая таблица не нужна будет, а сделать три и каждую связать с тремя таблицами по типу файла (audioDocs, photoDocs...)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2020, 17:46 |
|
||
|
Помощь с проектированием БД, клиенты, документы
|
|||
|---|---|---|---|
|
#18+
Vladimir_84_То есть эта промежуточная общая таблица не нужна будет, а сделать три и каждую связать с тремя таблицами по типу файла (audioDocs, photoDocs...)? Нет, таблицы по типу файла не нужны. Да и таблица Documents тоже сомнительна, хотя и радует поклонников нормальных форм. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2020, 18:18 |
|
||
|
Помощь с проектированием БД, клиенты, документы
|
|||
|---|---|---|---|
|
#18+
Понял, спасибо. Была идея сделать так. Но вот взбрело в голову, что разделить по типу файла будет наглядней. У меня типа диплома проект, думал, что на схеме так будет комиссии понятней. Так то не по базам специальность, код сам копать сильно то и не будут на этот счет, думаю. ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2020, 18:49 |
|
||
|
Помощь с проектированием БД, клиенты, документы
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov, вот переделал как посоветовали. Так вроде? Смущает таблица документы пользователя. Болтается одна без связей всяких. Но по логике так то вроде и должно... Никуда её не прицепить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2020, 23:15 |
|
||
|
Помощь с проектированием БД, клиенты, документы
|
|||
|---|---|---|---|
|
#18+
Vladimir_84_ Dimitry Sibiryakov, вот переделал как посоветовали. Так вроде? Изначальная схема была очень даже неплоха, а эта хуже - заметь, хотя бы, как у тебя в таблицах *Docs стали дублироваться поля. Если тебе пидется вводить еще один или несколько аттрибутов, которые должны быть у всех документов, то будешь каждый раз добавлять их во все таблицы. Или если появится еще один специфичный тип документов, для которого нужна будет отдельная таблица, то тоже надо будет копипастить. Поищи в интернете на тему представление наследования в реляционных БД - про это много написано, там несколько разных типовых подходов (TPH, TPC, TPT), у каждого свои плюс и минусы и надо выбирать по конкретной ситуации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2020, 01:42 |
|
||
|
Помощь с проектированием БД, клиенты, документы
|
|||
|---|---|---|---|
|
#18+
Vladimir_84_ Дальше не знаю... Я в общем-то нашёл проблему :) Попробуйте отложить схему БД в сторону и само проектирование. Представьте, что делать будет кто-то другой. Сможете написать требования? Напишите. Вы удивитесь, но хорошо прописанные требования дадут вам 80% пользы, останется накидать схему. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2020, 01:48 |
|
||
|
Помощь с проектированием БД, клиенты, документы
|
|||
|---|---|---|---|
|
#18+
fkthat, спасибо за совет. Почитаю. Может что получится придумать, а то немного запутался уже. hVostt, да, спасибо, попробую расписать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2020, 15:05 |
|
||
|
Помощь с проектированием БД, клиенты, документы
|
|||
|---|---|---|---|
|
#18+
Нужно всего три таблицы, если не вдаваться в подробности: 1. Клиенты. 2. Дела клиентов. 3. Документы. В "Клиентах" живут все клиенты, и физики и юрики. Это правильно с точки зрения построения БД, так как это одна сущность. Тип клиента это просто поле в этой таблице. В "Делах клиентов" живут все дела. Связь с "Клиентами" по ID клиента. В "Документах" живут все документы дел. Не клиентов, а именно дел, так как документы прежде всего привязаны к делу. Связь с таблицей "Дела клиентов" по ID дела. Тип документа (аудио, текст, графика) - поле в таблице. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2020, 09:36 |
|
||
|
Помощь с проектированием БД, клиенты, документы
|
|||
|---|---|---|---|
|
#18+
Stanislav P, разделение физ. и юр. лиц оправдано. Слишком разные у них реквизиты, которые важны. У физ. допустим Ф, И, О + дата рождения, а у юр. наименование (и то не обязательно), ОГРН или ИНН. Только по этим реквизитам можно однозначно идентифицировать клиента. Эти поля должны быть заполнены обязательно. Достичь этого имея одну общую таблицу невозможно. А документы не только к делу относятся. Допустим скан паспорта клиента физ. лица или скан доверенности. Эти документы должны храниться в одном экземпляре не зависимо от дела. Ведь по одной доверенности можно хоть в ста делах участвовать, а зачем тогда этот документ дублировать в каждом деле? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2020, 11:35 |
|
||
|
Помощь с проектированием БД, клиенты, документы
|
|||
|---|---|---|---|
|
#18+
Vladimir_84_ Stanislav P, разделение физ. и юр. лиц оправдано. Слишком разные у них реквизиты, которые важны. У физ. допустим Ф, И, О + дата рождения, а у юр. наименование (и то не обязательно), ОГРН или ИНН. Только по этим реквизитам можно однозначно идентифицировать клиента. Эти поля должны быть заполнены обязательно. Достичь этого имея одну общую таблицу невозможно. А документы не только к делу относятся. Допустим скан паспорта клиента физ. лица или скан доверенности. Эти документы должны храниться в одном экземпляре не зависимо от дела. Ведь по одной доверенности можно хоть в ста делах участвовать, а зачем тогда этот документ дублировать в каждом деле? Это неправильно. Так не делают. Делают признак "юрик/физик" и от него пляшут. Три таблицы превращаются в одну. И т.д. и т.п. Короче, кругом удобство. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2020, 11:46 |
|
||
|
Помощь с проектированием БД, клиенты, документы
|
|||
|---|---|---|---|
|
#18+
KreatorXXI Vladimir_84_ Stanislav P, разделение физ. и юр. лиц оправдано. Слишком разные у них реквизиты, которые важны. У физ. допустим Ф, И, О + дата рождения, а у юр. наименование (и то не обязательно), ОГРН или ИНН. Только по этим реквизитам можно однозначно идентифицировать клиента. Эти поля должны быть заполнены обязательно. Достичь этого имея одну общую таблицу невозможно. А документы не только к делу относятся. Допустим скан паспорта клиента физ. лица или скан доверенности. Эти документы должны храниться в одном экземпляре не зависимо от дела. Ведь по одной доверенности можно хоть в ста делах участвовать, а зачем тогда этот документ дублировать в каждом деле? Это неправильно. Так не делают. Делают признак "юрик/физик" и от него пляшут. Три таблицы превращаются в одну. И т.д. и т.п. Короче, кругом удобство. Я когда над этим думал, прошерстил и этот ресурс и другие на эту тему. Большинство сошлось на реализации как у меня. Потому что, в одной таблице половина полей будет не заполнена, в зависимости от типа клиента. Для юр. лица ОГРН или ИНН должны быть заполнены обязательно. А какой ОГРН у физ. лица, что тогда записывать туда для него? Это совершенно излишний атрибут. Какая-то солянка получится. По логике то да, это и то и то клиент, но исходя из предметной области сущности разные. Самолет и автомобиль то транспортные средства, но все же совершенно разные вещи. Да и ладно с этим, даже если б я в одну таблицу клиентов слил... У меня больше вопрос про таблицы документов исходя из их разных типов и разных владельцев. Как лучше все-таки разделить, по типу владельца? Исходя из первой схемы в голове складываются вроде запросы, достаточно просто получится вывести документы и по типу владельца и по типу файла... Приложение планируется однопользовательским, БД заполняться не будет быстро исходя из реалий. Поэтому какой-то сильной оптимизации и пр. не требуется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2020, 12:17 |
|
||
|
Помощь с проектированием БД, клиенты, документы
|
|||
|---|---|---|---|
|
#18+
Vladimir_84_ Stanislav P, разделение физ. и юр. лиц оправдано. Слишком разные у них реквизиты, которые важны. У физ. допустим Ф, И, О + дата рождения, а у юр. наименование (и то не обязательно), ОГРН или ИНН. Только по этим реквизитам можно однозначно идентифицировать клиента. Эти поля должны быть заполнены обязательно. Достичь этого имея одну общую таблицу невозможно. А документы не только к делу относятся. Допустим скан паспорта клиента физ. лица или скан доверенности. Эти документы должны храниться в одном экземпляре не зависимо от дела. Ведь по одной доверенности можно хоть в ста делах участвовать, а зачем тогда этот документ дублировать в каждом деле? Если у тебя будет две таблицы с клиентами (физики и юрики), то тебе нужно будет две таблицы на дела (отдельно физики и юрики) и то же самое с документами. Когда дойдёшь до построения форм, отчётов и поиска, то сразу поймёшь, что такое вложенный и длинный SELECT, и что такое две одинаковые формы на одну сущность клиент. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2020, 12:36 |
|
||
|
Помощь с проектированием БД, клиенты, документы
|
|||
|---|---|---|---|
|
#18+
Vladimir_84_Ведь по одной доверенности можно хоть в ста делах участвовать Нельзя. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2020, 12:46 |
|
||
|
Помощь с проектированием БД, клиенты, документы
|
|||
|---|---|---|---|
|
#18+
Vladimir_84_, Более "правильный" вариант - одна таблица "Клиенты", к ней таблица "Реквизиты клиента", а к ней таблица "Список реквизитов". Но тогда надо будет очень сильно заморачиваться с проектированием формы "Клиент". И хранить все реквизиты текстом, с дальнейшим преобразованием в нужный формат в программном коде. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2020, 12:56 |
|
||
|
Помощь с проектированием БД, клиенты, документы
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov Vladimir_84_Ведь по одной доверенности можно хоть в ста делах участвовать Нельзя. Ну как нельзя, если я этим занимаюсь =) Организация выдала доверенность на представление интересов в судах всех уровней и во всех гос. органах. И ходи с ней пока срок не закончится. Её же не забирают =) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2020, 12:59 |
|
||
|
Помощь с проектированием БД, клиенты, документы
|
|||
|---|---|---|---|
|
#18+
Stanislav P Vladimir_84_ Stanislav P, разделение физ. и юр. лиц оправдано. Слишком разные у них реквизиты, которые важны. У физ. допустим Ф, И, О + дата рождения, а у юр. наименование (и то не обязательно), ОГРН или ИНН. Только по этим реквизитам можно однозначно идентифицировать клиента. Эти поля должны быть заполнены обязательно. Достичь этого имея одну общую таблицу невозможно. А документы не только к делу относятся. Допустим скан паспорта клиента физ. лица или скан доверенности. Эти документы должны храниться в одном экземпляре не зависимо от дела. Ведь по одной доверенности можно хоть в ста делах участвовать, а зачем тогда этот документ дублировать в каждом деле? Если у тебя будет две таблицы с клиентами (физики и юрики), то тебе нужно будет две таблицы на дела (отдельно физики и юрики) и то же самое с документами. Когда дойдёшь до построения форм, отчётов и поиска, то сразу поймёшь, что такое вложенный и длинный SELECT, и что такое две одинаковые формы на одну сущность клиент. Да не, реквизиты дела не зависят от типа клиента, там все унифицированно. Типа статус клиента (истец, ответчик...), категория дела (гражданское, административное...), текстовое поле суть дела... Так что таблица одна. Вообще как это должно выглядеть - пользователь нажимает кнопку "Документы", дальше выбирает категорию -> "аудио", дальше чьи, допустим из списка -> клиент, дальше может фильтровать по конкретному клиенту. Там прям в окне может файл прослушать, удалить, и пр. Так же с другими категориями владельца файла и категориями файла. Допустим для фото будет предпросмотр прям в окне интерфейса приложения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2020, 13:06 |
|
||
|
Помощь с проектированием БД, клиенты, документы
|
|||
|---|---|---|---|
|
#18+
Stanislav P Vladimir_84_, Более "правильный" вариант - одна таблица "Клиенты", к ней таблица "Реквизиты клиента", а к ней таблица "Список реквизитов". Но тогда надо будет очень сильно заморачиваться с проектированием формы "Клиент". И хранить все реквизиты текстом, с дальнейшим преобразованием в нужный формат в программном коде. Ну так наверное правильней, да. Но вот заморачиваться как раз не очень хочется. Я же говорю, я не спец по БД совсем, делаю как понимаю. Чтобы прям все по теории было сто процентов не обязательно. Смотрю на примеры тут же с форума, как другие делают и советуют. Мне главное, чтобы работало сейчас все =). Часть с клиентами и делами уже написана и протестирована, все ок. Ссылочная целостность по ключам проверяется, на уровне логики приложения тоже проверки есть. Мне документы прикрутить надо =) Когда приложение будет готово, если время будет, рефакторинг произведу если что, в этой части ("Клиент") тоже. Не могу сейчас тормознуть процесс и сильно переписывать код. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2020, 13:14 |
|
||
|
Помощь с проектированием БД, клиенты, документы
|
|||
|---|---|---|---|
|
#18+
Vladimir_84_Ну как нельзя, если я этим занимаюсь =) Хорошо, что я никогда не буду Вашим клиентом. Нет риска, что Вы подадите в суд на Путина, проиграете и загоните меня в гроб, воспользовавшись доверенностью на вымогание задолженности в сто рублей. Vladimir_84_Для юр. лица ОГРН или ИНН должны быть заполнены обязательно. А какой ОГРН у физ. лица, что тогда записывать туда для него? Для чего? Если клиенты доверяют Вам, значит и Вы должны доверять клиентам. Поэтому можно не закладываться на то, что один клиент начнёт выдавать себя за другого. Нет необходимости поиска по 100500 атрибутам, нет смысла их хранить. Vladimir_84_Вообще как это должно выглядеть - пользователь нажимает кнопку "Документы", дальше выбирает категорию -> "аудио", дальше чьи, допустим из списка -> клиент, дальше может фильтровать по конкретному клиенту. Там прям в окне может файл прослушать, удалить, и пр. Зачем такой длинный путь? Это неэргономично. Карточка клиента, кнопка "Документы" откроет окно с полным списком его документов всех видов. Далее кнопка "посмотреть" откроет конкретный документ. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2020, 13:20 |
|
||
|
Помощь с проектированием БД, клиенты, документы
|
|||
|---|---|---|---|
|
#18+
Vladimir_84_Мне документы прикрутить надо =) Просто сложите их в определённую папку и по кнопке "Документы" открывайте окно проводника. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2020, 13:29 |
|
||
|
Помощь с проектированием БД, клиенты, документы
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov, Ну в доверенности можно прописать конкретно по каким делам представляются интересы и где. Допустим пять штук в одном суде. Это к тому, что наверное не зачем хранить одну доверенность в пяти экземплярах в разных делах. Поэтому и хочется это отделить. Про ОГРН или ИНН. Это уникальный идентификатор. В общей таблице может быть десять ООО "Ромашка", но это будут разные юр. лица. Вот чтобы можно было их однозначно различать и надо указать одно из двух. Про длинный путь, я с вами соглашусь, так и будет. Интерфейс ещё продумывается. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2020, 13:38 |
|
||
|
Помощь с проектированием БД, клиенты, документы
|
|||
|---|---|---|---|
|
#18+
Vladimir_84_Это уникальный идентификатор. В общей таблице может быть десять ООО "Ромашка", но это будут разные юр. лица. Вот чтобы можно было их однозначно различать и надо указать одно из двух. У Вас есть десять клиентов с одним названием и Вы способны их различить только по номеру? Не надо маяться теоретической фигнёй, делая приложение для конкретного собственного использования. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2020, 13:43 |
|
||
|
|
start [/forum/topic.php?fid=32&fpage=3&tid=1539843]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
28ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
72ms |
get tp. blocked users: |
2ms |
| others: | 239ms |
| total: | 391ms |
| 0 / 0 |
