Я хотел бы извлечь некоторые данные из трех таблиц в базе данных SQL Server 2005. Хотя это, безусловно, можно сделать в коде, кажется, что это можно сделать достаточно хорошо в SQL (бонусные баллы за LINQ!).
По сути, я хотел бы знать за каждый месяц, сколько звонков и встреч провел каждый сотрудник с каждым из наших клиентов. Что-то вроде этого:
Employee GUID Customer GUID Jan calls Jan mtgs Feb calls Feb mtgs...
[a guid] [another guid] 5 0 7 3
Данные распределены по трем таблицам. Для простоты давайте просто покажем соответствующие столбцы:
Таблица связи
[CommunicationId] (PK, uniqueidentifier)
[Type] (nvarchar(1)) ('C' for call, 'M' for meeting, etc.)
[Date] (datetime)
Таблица общения между людьми
[PersonId] (PK, FK, uniqueidentifier) (Can contain GUIDs for employees or clients, see Person Table below)
[CommunicationId] (PK, FK, uniqueidentifier)
Таблица лиц
[PersonId] (PK, uniqueidentifier)
[Type] (nvarchar(1)) ('E' for employee, 'C' for customer)
Итак, вопросы:
- Можно ли это сделать в SQL без ужасного кода или больших проблем с производительностью?
- Если да, то как? Я бы даже согласился на хорошую высокоуровневую стратегию. Я предполагаю, что большую роль здесь будут играть стержни (особенно «Сложный пример PIVOT»). DATEPART(MONTH, Date) кажется хорошим методом разделения сообщения по месяцам по линиям:
SELECT DATEPART(MONTH, Date), COUNT(*) FROM [CommunicationTable] WHERE DATEPART(YEAR, Date) = '2009' GROUP BY DATEPART(MONTH, Date) ORDER BY DATEPART(MONTH, Date)
... что дает мне количество сообщений в каждом месяце в 2009 году:
1 2871
2 2639
3 3654
4 2751
5 1773
6 2575
7 2906
8 2398
9 2621
10 2638
11 1705
12 2290
uniqueidentifier
не подразумевает ограничениеUNIQUE
. - person Quassnoi   schedule 24.02.2010uniqueidentifier
- это термин SQL Server для GUID. Несколько человек могут быть связаны с несколькими сообщениями (но только один раз, например, три раза быть связанным с телефонным звонком бессмысленно и недопустимо). - person Kevin L.   schedule 24.02.2010nvarchar(1)
наchar(1)
: вам не нужно сохранять длину и определенно не нужно поддерживать больше, чем ASCII. Тем более, что вы выполняете поиск по этим столбцам, у вас могут быть индексы, включающие их, размер которых будет влиять на производительность (и, как правило, размер таблицы). - person van   schedule 24.02.2010