|
|
|
Как лучше организовать каталог партнеров
|
|||
|---|---|---|---|
|
#18+
Дано: Каталог партнеров. Партнеры представляют собой фирмы с 1..Н работниками. В базе должна храниться информация как о фирме, так и о работниках. Фирмы имеют категории, точно так же как и их работники имеют свои отдельные категории. Например: строительная фирма и ее работники: монтажники, маляры и т.д. В роли фирмы может выступать и отдельно взятый человек, например индивидуальный преприниматель. Мое решение: Создать таблицу "Партнер", в которой будут храниться оба типа объектов, фирмы их работники будут связаны между собой ключом, индивидуальные предприниматели такого ключа иметь не будут и будут представлять собой фирмы. Вопрос: Оптимально ли мое решение, или можно это как-нибудь по-другому реализовать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2013, 13:56 |
|
||
|
Как лучше организовать каталог партнеров
|
|||
|---|---|---|---|
|
#18+
saturnxxiДано: Каталог партнеров. Партнеры представляют собой фирмы с 1..Н работниками. В базе должна храниться информация как о фирме, так и о работниках. Фирмы имеют категории, точно так же как и их работники имеют свои отдельные категории. Например: строительная фирма и ее работники: монтажники, маляры и т.д. В роли фирмы может выступать и отдельно взятый человек, например индивидуальный преприниматель. Мое решение: Создать таблицу "Партнер", в которой будут храниться оба типа объектов, фирмы их работники будут связаны между собой ключом, индивидуальные предприниматели такого ключа иметь не будут и будут представлять собой фирмы. Вопрос: Оптимально ли мое решение, или можно это как-нибудь по-другому реализовать? Cмотря как сильно пересекаются у Вас множества атрибутов партнера и работника. Если пересекаются не очень - возможно, лучше сделать все-таки 2 таблицы, partner и person, с двумя связями [0..1] и [1..N] ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2013, 14:54 |
|
||
|
Как лучше организовать каталог партнеров
|
|||
|---|---|---|---|
|
#18+
Кот Матроскин, а как же мне потом организовать выборку, если у меня будет несколько таблиц? Т.е. я хочу видеть к примеру последних добавленых н партнеров. Придется ведь обе таблицы опрашивать каждый раз. Или тот же поиск по категориям партнеров. Ведь у индивидуальных предпренимателей тогда не будет связи с категориями фирм, если я их буду хранить в отдельной таблице. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2013, 15:05 |
|
||
|
Как лучше организовать каталог партнеров
|
|||
|---|---|---|---|
|
#18+
saturnxxi, Нет, индивидуального предпринимателя Вы сохраняете в обе таблицы. В Partner есть ссылка на Person ( связь "учредитель", мощность [0..1]), в Person - ссылка на Partner ( связь "работник", мощность [0..N]). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2013, 15:13 |
|
||
|
Как лучше организовать каталог партнеров
|
|||
|---|---|---|---|
|
#18+
Кот Матроскин, Хранить один и тот же объект в двух таблицах? Хм, не проще ли тогда делать как я это предложил? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2013, 15:57 |
|
||
|
Как лучше организовать каталог партнеров
|
|||
|---|---|---|---|
|
#18+
saturnxxiКот Матроскин, а как же мне потом организовать выборку, если у меня будет несколько таблиц? Т.е. я хочу видеть к примеру последних добавленых н партнеров. Придется ведь обе таблицы опрашивать каждый раз. Или тот же поиск по категориям партнеров. Ведь у индивидуальных предпренимателей тогда не будет связи с категориями фирм, если я их буду хранить в отдельной таблице. Не городите велосипед... Да еще и кривой )) ИП - та же фирма (имеет такие же аттрибуты - счет, ИНН, КПП). У ИП могут быть работники (а может и не быть). Так что делать нужно 1) таблицу фирм (куда будут добавляться и ИП) 2) таблицу справочник Категорий фирм (например строительная фирма) 3) Таблицу сотрудников фирм 4) Таблицу справочник должностей P.S. А обращение к 2 таблицам - это не страшно... Даже в средних системах может быть одновременное обращение к 10-ам таблиц... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2013, 16:01 |
|
||
|
Как лучше организовать каталог партнеров
|
|||
|---|---|---|---|
|
#18+
saturnxxiКот Матроскин, Хранить один и тот же объект в двух таблицах? Хм, не проще ли тогда делать как я это предложил? Это не одно и тоже... В таблице фирм Вы храните данные ИП, как фирме (Наименование, ИНН, КПП, Счет, Банк, Адрес, Адрес склада, и много еще какой информации можно придумать )) ) В Таблице сотрудников Вы храние данные ИП как человека (ФИО, контактный телефон, где найти). Да и по наименованию: раньше был "ПБОЮЛ Иванов И.И.", сейчас "ИП Иванов И.И", а человек как был Иванов Иван Иванович, так им и остался... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2013, 16:06 |
|
||
|
Как лучше организовать каталог партнеров
|
|||
|---|---|---|---|
|
#18+
lLocust, Спасибо, за пространственный ответ. Множества аттрибутов (вы слишком много их додумали за меня) действительно пересекаются. Если я вынесу адрес в отдельную таблицу, то они будут практически идентичны. Не могли бы вы мне пояснить, почему мое решение нерационально? Исходите пожалуйста при этом только из той информации, что я написал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2013, 16:24 |
|
||
|
Как лучше организовать каталог партнеров
|
|||
|---|---|---|---|
|
#18+
saturnxxi, Лучше приложи схему, а то в итоге так и непонял чего ты там где хочешь хранить. Визуально всетаки воспринимается лучше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2013, 16:28 |
|
||
|
Как лучше организовать каталог партнеров
|
|||
|---|---|---|---|
|
#18+
saturnxxi Не могли бы вы мне пояснить, почему мое решение нерационально? Исходите пожалуйста при этом только из той информации, что я написал. При Вашей схеме Вам надо в каждом запросе отсекать обьекты "не того" типа - поскольку физически они лежат в той же таблице. К примеру, запрос "сколько людей зарегистрировано в нашей системе?" у Вас будет выглядеть сложнее (возможно - существенно сложнее), чем Код: sql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2013, 16:31 |
|
||
|
Как лучше организовать каталог партнеров
|
|||
|---|---|---|---|
|
#18+
saturnxxilLocust, Спасибо, за пространственный ответ. Множества аттрибутов (вы слишком много их додумали за меня) действительно пересекаются. Если я вынесу адрес в отдельную таблицу, то они будут практически идентичны. Не могли бы вы мне пояснить, почему мое решение нерационально? Исходите пожалуйста при этом только из той информации, что я написал. Ну тогда Вы по-подробнее опишите что в итоге нужно? Если Вам нужно хранить ИП как работника - храните. Жалко, что ли? Если у Вас фирма отличается от человека только адресом, то зачем вообще вводить какие-то понятия... Храните все в одной таблице, а адреса в другой... Только потом (когда придет бизнес и скажет что хочет у фирмы одни атрибуты, а у их работников другие) что делать будите? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2013, 16:44 |
|
||
|
Как лучше организовать каталог партнеров
|
|||
|---|---|---|---|
|
#18+
lLocust... будите ?... * будете ... ( что-то глупые ошибки пошли к концу дня ))) ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2013, 16:47 |
|
||
|
Как лучше организовать каталог партнеров
|
|||
|---|---|---|---|
|
#18+
saturnxxilLocust, Спасибо, за пространственный ответ. Множества аттрибутов (вы слишком много их додумали за меня) действительно пересекаются. Если я вынесу адрес в отдельную таблицу, то они будут практически идентичны. Не могли бы вы мне пояснить, почему мое решение нерационально? Исходите пожалуйста при этом только из той информации, что я написал. Ах, да... и Как я уже говорил: У меня отец был предпринимателем. Сначала по документам он был "ПБОЮЛ Курочкин Н.И", потом то ли прошел перерегистрацию, то ли налоговая сама поменяла на "ИП Курочкин Н.И", а в жизни он "Курочкин Никифр Игнатьевич". Есть разница? (Имена, естественно выдуманы :) ) А Вы что будете хранить? ИП как ФИО, или ФИО как ИП ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2013, 16:53 |
|
||
|
Как лучше организовать каталог партнеров
|
|||
|---|---|---|---|
|
#18+
При Вашей схеме Вам надо в каждом запросе отсекать обьекты "не того" типа - поскольку физически они лежат в той же таблице. К примеру, запрос "сколько людей зарегистрировано в нашей системе?" у Вас будет выглядеть сложнее (возможно - существенно сложнее), чем... Это серьезный довод. Ну тогда Вы по-подробнее опишите что в итоге нужно? Если Вам нужно хранить ИП как работника - храните. Жалко, что ли? Если у Вас фирма отличается от человека только адресом, то зачем вообще вводить какие-то понятия... Храните все в одной таблице, а адреса в другой... В уже существующей схеме все реализованно так, как вы и предлагаете, т.е. фирма - работник (1 к Н). Выборка в большинстве случаев происходит по фирме, есть также возможность искать конкретного специалиста по специальности. Для создания есть 2 формы: для фирмы с возможностью выбора специализации фирмы и форма для рабочего с возможностью выбора его собственной специализации. Цель - возможность учитывать ИП. (или, если точнее, людей работающих в одиночку). Т.е. если я просто буду делать из ИП фирму, то нет возможности выбрать специализацию рабочего, если буду делать из него рабочего, то нет связи со специализацией фирмы. Опять же, как я уже сказал, выборка происходит почти везде по фирмам и если я оставлю 2 таблицы, то мне нужно будет как-то комбинировать результаты выборок из 2 таблиц. Сортировка, постраничный вывод, давай до свидания. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2013, 18:24 |
|
||
|
Как лучше организовать каталог партнеров
|
|||
|---|---|---|---|
|
#18+
saturnxxiВ уже существующей схеме все реализованно так, как вы и предлагаете, т.е. фирма - работник (1 к Н). Выборка в большинстве случаев происходит по фирме, есть также возможность искать конкретного специалиста по специальности. Для создания есть 2 формы: для фирмы с возможностью выбора специализации фирмы и форма для рабочего с возможностью выбора его собственной специализации. Цель - возможность учитывать ИП. (или, если точнее, людей работающих в одиночку). Т.е. если я просто буду делать из ИП фирму, то нет возможности выбрать специализацию рабочего, если буду делать из него рабочего, то нет связи со специализацией фирмы. Опять же, как я уже сказал, выборка происходит почти везде по фирмам и если я оставлю 2 таблицы, то мне нужно будет как-то комбинировать результаты выборок из 2 таблиц. Сортировка, постраничный вывод, давай до свидания. У Вас, как я понимаю, специализации фирмы и сотрудника хранятся как текстовые поля? (Иначе такой вопрос и не стоял бы, т.к. справочники специализаций фирм и сотрудников отличаются кардинально!!!). Вообще можно не комбинировать результаты выборок. А просто сделать запрос сразу из двух таблиц, тогда и сортировка и постраничный вывод будут работать. Вообще я бы сделал так: (см. схему). 1) Специализации завести как отдельные таблицы. 2) Дополнительно завести связи (Т.к. у фирмы/сотрудника может быть несколько специализаций). 3) При добавлении ИП (на форме сделать выбор типа организации) добавлять поля для редактирования таблицы сотрудников (и связи сотрудника с его специализациями). Но физически данные хранить в двух(!) таблицах. По фирме в своей, по сотруднику в своей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2013, 19:03 |
|
||
|
Как лучше организовать каталог партнеров
|
|||
|---|---|---|---|
|
#18+
Всем большое спасибо за помощь. Думаю, что так и поступлю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2013, 20:26 |
|
||
|
Как лучше организовать каталог партнеров
|
|||
|---|---|---|---|
|
#18+
Улыбнуло :) Теоретические рассуждения студентов. Представленная схема полетит к чертям в реальной жизни и при большом охвате. Например, ООО "Лютик" в мегаполисе может быть несколько десятков, заполненность атрибутов и их достоверности может не быть по определению, кто когда в какой компании работал - тоже тот еще вопрос отследить и т.д. и т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2013, 20:27 |
|
||
|
Как лучше организовать каталог партнеров
|
|||
|---|---|---|---|
|
#18+
авторООО "Лютик" в мегаполисе может быть несколько десятков И черт с ним. У всех этих ООО должны отличаться ОКПО (идентификтаор предприятия) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.08.2013, 23:37 |
|
||
|
Как лучше организовать каталог партнеров
|
|||
|---|---|---|---|
|
#18+
londiniumавторООО "Лютик" в мегаполисе может быть несколько десятков И черт с ним. У всех этих ООО должны отличаться ОКПО (идентификтаор предприятия) И пара ИНН/КПП )) А вообще так про любую схему можно сказать, что как только она столкнется с реалиями жизни, то все не будет работать, вот только это уже больше административный вопрос (я про неправильно заполненные атрибуты). Так что лучше на бумаге! да, ssas12345? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.08.2013, 10:19 |
|
||
|
Как лучше организовать каталог партнеров
|
|||
|---|---|---|---|
|
#18+
ssas12345Улыбнуло :) Теоретические рассуждения студентов. Представленная схема полетит к чертям в реальной жизни и при большом охвате. Например, ООО "Лютик" в мегаполисе может быть несколько десятков, заполненность атрибутов и их достоверности может не быть по определению, кто когда в какой компании работал - тоже тот еще вопрос отследить и т.д. и т.п. И вам спасибо за ваши мысли. Я уже просил выше, что не нужно за меня ничего додумывать, исходите лишь из того, что я написал. Если у вас есть конкретные предложения по реализции, я с удовольствием их выслушаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.08.2013, 11:25 |
|
||
|
Как лучше организовать каталог партнеров
|
|||
|---|---|---|---|
|
#18+
saturnxxi, поскольку схему своих решений вы не предложили, а предложил только lLocust то додумывать приходится. Так, как минимум в схеме должно быть отражено решение по идентификации и унификации фирм. ИНН/КПП не всегда могут быть известны. Если желтенькие lookup-таблицы такие какие представлены, без различающихся доп. атрибутов, то их можно свести в одну таблицу Как будут учитываться понятия холдинга, групп компаний? (а Заказчик или жизнь - они это запросят рано или поздно) Как будут учитываться периоды актуальности информации? Сотрудники имеют характеристику иерархичности, требуют систематизации, т.к. просто список в 3-5 тысяч ФИО - вряд ли удачное решение. Также, нередко интересна инфа о первых лицах компаний Каталог партнеров - слово каталог очень сильное - то не просто накидать пару табличек. lLocust, Про бумажный учет я ничего не говорил. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.08.2013, 13:49 |
|
||
|
Как лучше организовать каталог партнеров
|
|||
|---|---|---|---|
|
#18+
ssas12345Если желтенькие lookup-таблицы такие какие представлены, без различающихся доп. атрибутов, то их можно свести в одну таблицу ... и сотрудникам начнут назначаться специализации фирм, а фирмам - специальности сотрудников. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.08.2013, 14:44 |
|
||
|
Как лучше организовать каталог партнеров
|
|||
|---|---|---|---|
|
#18+
Кот Матроскинssas12345Если желтенькие lookup-таблицы такие какие представлены, без различающихся доп. атрибутов, то их можно свести в одну таблицу ... и сотрудникам начнут назначаться специализации фирм, а фирмам - специальности сотрудников. Кот Матроскин, ну что же вы право, где я такое допускал? Формат хранения <> способ биндинга к формам GUI. Надеюсь, у автора будет Data Layer, из которого обращение к БД организовано посредством параметризованных хранимых процедур. Если хорошо сделать Data Layer, то можно хоть толстый хоть тонкий клиент натягивать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.08.2013, 14:56 |
|
||
|
Как лучше организовать каталог партнеров
|
|||
|---|---|---|---|
|
#18+
ssas12345Кот Матроскинпропущено... ... и сотрудникам начнут назначаться специализации фирм, а фирмам - специальности сотрудников. Кот Матроскин, ну что же вы право, где я такое допускал? Формат хранения <> способ биндинга к формам GUI. Надеюсь, у автора будет Data Layer, из которого обращение к БД организовано посредством параметризованных хранимых процедур. Если хорошо сделать Data Layer, то можно хоть толстый хоть тонкий клиент натягивать. Мы обсуждаем БД, а не "биндинг к формам GUI". В БД - кривизна, и говорить "Ну и что что кривизна, я ее пофиксю биндингом к формам GUI" - подход, мягко говоря, не рекомендуемый. Данные в БД могут изменяться и вообще без GUI, и с несколькими независимыми клиентами, не все из которых Вы контролируете, и т.п. Поэтому весьма желательно не надеяться на "биндинг к формам GUI", "Data Layer" и делать БД так, чтобы некорретные данные туда занести было невозможно. Причем ладно бы от обсуждаемого обьединения таблиц был какой-то заметный смысл - да, иногда приходится пожертвовать надежностью, чтолбы выиграть что-то еще. Но тут-то где выигрыш, кроме того что на 1 объект в БД меньше? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.08.2013, 19:50 |
|
||
|
Как лучше организовать каталог партнеров
|
|||
|---|---|---|---|
|
#18+
Кот Матроскин, для простых lookUp-ов плодить кучу таблиц - накладно и поддержка и схему засорять объектами. То, что таких табличек будет много в большой системе - можно не сомневаться [про большую систему намекает термин -Каталог партнеров] Насчет обновления данных минуя GUI и DataLayer - тоже вестимо, не первая пятилетка стажа за плечами. Так, задачу соблюдения функциональной зависимости также соблюдается, обеспечивается соотв. функционалом СУБД. Другое дело, если lookUp-таблица все же окажется полноценной сущностью, то тогда да - расписываем атрибуты по полной. saturnxxi, еще одна рекомендация: проектируя схему, хорошо бы иметь приличный массив реальных данных, который хорошо проанализировать, профилировать; поинтересоваться, уяснить возможное будущее развитие системы; посмотреть примеры из известных больших решений - нужно перенять p.s. Качество своих баз данных я очень жестко контролировал и контролирую. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.08.2013, 20:33 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=38372482&tid=1541138]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
147ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
| others: | 232ms |
| total: | 471ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...