Период между сообщениями больше года.
|
|
|
Как целесообразно описать данные?
|
|||
|---|---|---|---|
|
#18+
Есть один тип клинетов и второй тип клиентов. У каждого типа клиентов свой набор атрибутов. И тот и другой тип клиентов учитывается в момей системе. Стоирт ли для каждого типа клиентов организовывать свою сущность? Или запихать основные поля в одну сущность и признак типа клиента в лепить. А для каждого атрибута иметь также свою сущность с признаком того клиента который его использует... А? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.08.2005, 14:48 |
|
||
|
Как целесообразно описать данные?
|
|||
|---|---|---|---|
|
#18+
Клиент типа 1 легким движением руки может превращаться в клиента типа 2? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.08.2005, 20:46 |
|
||
|
Как целесообразно описать данные?
|
|||
|---|---|---|---|
|
#18+
AlexG А для каждого атрибута иметь также свою сущность с признаком того клиента который его использует нет это неверно можно через таблицы со связью многие-ко-многим создавать "конфигурации" клиентов, тогда их может быть и не 1-2 а 100-200 разных типов (обладающих несовпадающими наборами аттрибутов) что опять спор на тему физики-юрики? тут по форуму есть материал по этому поводу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2005, 10:47 |
|
||
|
Как целесообразно описать данные?
|
|||
|---|---|---|---|
|
#18+
Ни в коем случае не делите клиентов на сущности. Отличайте их по признакам, находящимся в отдельной таблице. Тогда клиенту можно присвоить бесконечное число признаков, и группировать их (клиентов) можно по общим признакам и их комбинациям. Подход гибкий, т.к. позволяет сделать бесконечную комбинацию общих и отличительных признаков. сущности: * Клиенты * Признаки * Связка Клиент-Признак ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2005, 11:56 |
|
||
|
Как целесообразно описать данные?
|
|||
|---|---|---|---|
|
#18+
LSVНи в коем случае не делите клиентов на сущности. Отличайте их по признакам, находящимся в отдельной таблице. Тогда клиенту можно присвоить бесконечное число признаков, и группировать их (клиентов) можно по общим признакам и их комбинациям. Подход гибкий, т.к. позволяет сделать бесконечную комбинацию общих и отличительных признаков. сущности: * Клиенты * Признаки * Связка Клиент-Признак Вы правы, если тип клиента не является типом пользователя, и как следствие типом приложения ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2005, 12:23 |
|
||
|
Как целесообразно описать данные?
|
|||
|---|---|---|---|
|
#18+
Тип клиента - он же тип объекта :) но для твоего примера это все контрагенты - хранить в 1 сущности. Можно разнести на уровне интерфейса в псевдоразные справочники. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2005, 15:27 |
|
||
|
Как целесообразно описать данные?
|
|||
|---|---|---|---|
|
#18+
Я подниму.... Свои собственные фирмы хранить в том же справочнике контрагентов? Персонал фирмы там же? Естетственно доп атрибуты в своих таблицах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2006, 14:23 |
|
||
|
Как целесообразно описать данные?
|
|||
|---|---|---|---|
|
#18+
Расширю вопрос - что имею сечас в акцесе: 1 список реальных фирм 2 список юрлиц (много-к-одному к списку реальных фирм), счета выписываются и балансы считаются по реальной фирме + дополнительно ставиться юрлицо - на которое выписывается документ и ведется БУ 3 список контактных лиц фирм - должности, телефоны, дни рождений 4 персонал компании (дублируется на 30% в списке реальных фирм для выписки счетов и ведения балансов) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2006, 14:35 |
|
||
|
Как целесообразно описать данные?
|
|||
|---|---|---|---|
|
#18+
Я храню в одном реестре даже подразделения и персонал нашей компании:так проще,так как у нас сделку может заключить как вся компания,так и подразделение,так и отдельный человек. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2006, 16:42 |
|
||
|
Как целесообразно описать данные?
|
|||
|---|---|---|---|
|
#18+
> храню в одном реестре даже подразделения и персонал нашей компании С одной стороны, для контрагентов не требуется детализация и достоверность, которая необходима для владельца. Кроме того, структура компании может быть достаточно сложной и ее описание может представлять собой отдельную задачу. С другой стороны, избыточная структура данных, позволяющая исчерпывающе полно описывать любых контрагентов - идеологически правильное решение. ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2006, 17:10 |
|
||
|
Как целесообразно описать данные?
|
|||
|---|---|---|---|
|
#18+
в системе разработаны механизмы,про которые уже я писал,которые позволяют описать практически любые связи между субъектами,поэтому этим же инструментом все и описывается,поэтому в то время,как другие решают как делать холдинги-шмолдинги и прочее,мы живем и поем.Спасибо за понимание идеологии:мы изначально приняли решение,что любой персонаж,который может быть связан с нашей компанией должен лежать в общем едином реестре. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2006, 17:53 |
|
||
|
Как целесообразно описать данные?
|
|||
|---|---|---|---|
|
#18+
> позволяют описать практически любые связи между субъектами Да, я помню это обсуждение. Единственное, что мы тогда не обсудили (если я ничего не путаю) - это как вы живете без тезауруса. ;) Или он все-таки есть? Или у вас какой-то другой механизм семантических связей? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2006, 19:15 |
|
||
|
|
start [/forum/topic.php?fid=32&fpage=132&tid=1545019]: |
0ms |
get settings: |
8ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
76ms |
get topic data: |
13ms |
get forum data: |
4ms |
get page messages: |
64ms |
get tp. blocked users: |
2ms |
| others: | 233ms |
| total: | 428ms |
| 0 / 0 |
