Разработка базы данных, группировка контактов по спискам и компаниям - PullRequest
0 голосов
/ 08 июня 2010

Мне интересно, что было бы лучшим способом группировать контакты по их компании.Прямо сейчас пользователь может группировать свои контакты по специально созданным спискам , но я хотел бы иметь возможность группировать контакты по их компании , а также сохранять положение контакта (то есть Руководитель проекта компании XYZ).

Для базы данных это то, что я имею для группировки контактов в списки

contact
[id_contact] [int] PK NOT NULL,
[lastName] [varchar] (128) NULL,
[firstName] [varchar] (128) NULL,
......

contact_list
[id_contact] [int] FK,
[id_list] [int] FK,

список
[id_list] [int] PK
[id_user] [int] FK
[list_name] [varchar] (128) NOT NULL,
[описание] [TEXT] NULL

Должен ли я реализовать нечто подобное для группировки контактов по компании?Если да, то как мне сохранить позицию контакта в этой компании и как я могу предотвратить повреждение данных, если пользователь изменит название компании контакта.Например, Джон Доу сменил компанию, но другие сотрудники все еще в старой компании.

Я сомневаюсь, что это случится часто (может даже не случиться вообще), но лучше быть в безопасности, чем сожалеть.Я также веду контрольный журнал, так что контакт должен был бы быть связан со старой компанией, а также с новой, но не путая, в какой компании он сейчас работает.

Надеюсьэто имело смысл ... Кто-нибудь сталкивался с такой проблемой?


ОБНОВЛЕНИЕ

Было бы что-то вроде этого иметь смысл

contact_company
[id_contact_company][int] PK
[id_contact] [int] FK
[id_company] [int] FK
[contact_title] [varchar] (128)

компания
[id_company] [int] PK NOT NULL,
[company_name] [varchar] (128) NULL,
[company_description] [varchar] (300) NULL,
[create_date] [datetime] NOTNULL

Таким образом, контакт может работать для более чем одной компании, и контакты могут быть сгруппированы по компаниям

1 Ответ

1 голос
/ 28 июля 2010

То, что у вас есть вместе с обновлением, выглядит примерно так.

Итак, на мой взгляд, у вас есть пользователи, и у каждого пользователя есть основной список контактов.У пользователя также есть дополнительные списки для организации контактов в основном списке.Каждый контакт имеет свое имя и контактную информацию, а также несколько компаний, в которых они работали, плюс они должны отслеживать свою текущую компанию.

Хранение компаний в отдельной таблице было хорошей идеей.Обычно текстовое поле будет работать, но поскольку вы планируете использовать компании больше как отдельные объекты, лучше всего подойдет отдельная таблица.

Мне кажется, что я повторяю то, что у вас есть, но я поставлю то, что кажетсялучшая настройка.Я просто пишу следующее с моими соглашениями (подчеркивание означает один ко многим):

*user*
id [int PK], 
... 

*user_contact*
id [int PK], 
user [int FK (user)], 
currentCompany [int FK (company)] 
... 

*user_contact_company*
id [int PK], 
contact [int FK (user_contact)], 
company [int FK (company)], 
startDate [date],
endDate [date]
...

*user_contactList*
id [int PK],
user [int FK (user)]
... 

*user_contactList_contact*
id [int PK], 
contactList [int FK (user_contactList)], 
contact [int FK (contact)] 
...

*company*
id [int PK] 
... 

Затем для базовой группировки:

SELECT * FROM `user_contact` WHERE `user` = <USER_ID> GROUP BY `currentCompany`

Но я не думаю,это будет работать так, как вы хотите, поэтому у вас может быть два запроса:

SELECT DISTINCT `currentCompany` FROM `user_contact` WHERE `user` = <USER_ID>

Тогда для каждой компании:

SELECT * FROM `user_contact` WHERE `company` = <COMPANY>

Есть много других способов сделать это, в зависимости ото том, как вы планируете это реализовать.Например, вы можете просто сделать ORDER BY, чтобы все компании были сгруппированы, и тогда ваш код, который отображает компании, может увидеть, отличается ли текущая компания от предыдущей, и провести правильное различие.

Что касается позиций компании, вы можете подумать о том, чтобы сделать текст или сослаться на другую таблицу, в зависимости от того, как вы ее используете.Если вы собираетесь выполнять сортировку, например, «Диспетчер проектов» будет сгруппирован с другими «Диспетчерами проектов», то он должен находиться в другой таблице, в противном случае кто-то может выбрать другое имя, нежели «Диспетчер проектов», или сделать имя строчнымдаже если они семантически одинаковы.

...