SQL: тип "Список сторон"

[zloboglot]

в sql запросе нужно связать две таблицы - звонок и юзер - условием 'если звонок адресован юзеру'.
со стороны юзера есть userid, со стороны звонка - поле to (приходится в квадратные скобки его, дабы не считалось ключевым словом), которое является неким мифическим типом "список сторон". обращения вида call.[to][1] = user.userid не работают (ругается на синтаксис вокруг единицы). на нулевую индексацию ругается так же.
вопрос: как оттуда выдернуть первое поле, чтобы проверить адресата? или, может быть, есть что то вроде if ([to].contains(userid))?

гугл по запросу "crm 'список сторон'" дает 4 ссылки, по 'sql 'список сторон'' - 8, из них полезных ни одной. все, что нашел по массивам в sql, предлагает обращение чуть ли не через vba с описанием собственных контейнеров под то-что-вернет-запрос.

[Артем Enot Грунин]

Вы простите, но массивы и индексаторы в SQL - это сильно! Про "мифический список сторон" - тем более убило. Я думаю, вам нужно почитать про синтаксис SQL, про разработку отчетов для CRM и вообще найти разработчика!

А начать нужно со следующего: Изучение конструкции Join, свезей Many to Many, диаграмм структуры базы CRM.

[zloboglot]

Вы простите, но я был удивлен не меньше вашего. Я вполне знаю что такое join - просто разработчик, который делал знакомым базу, оказался, несмотря на свои масштабы и красивые презентации, довольно гнусным - там отдельные таблицы под сущность - кодгорода, сущность - город, сущность - почтовый индекс; около 40 полей адреса, заполненное из которых только одно и т д. Делали эту базу упоротые наркоманы (причем переделать все нельзя - простой обойдется слишком дорого), а мне приходится помогать разгрести завалы.

Я не знаю, сделали ли они сами тип данных "список сторон", либо это один из стандартных типов crm.
Я не смог за два дня гугления найти инфы по этому поводу ни в рунете, ни в всеобщем.
Сюда я обратился, чтобы мне либо сказали "это дефолтный тип crm, инфа по нему здесь", либо сказали "это developer-defined и ищи его в settings->config->blablabla->...->datatypes.src", либо сказали "это developer-defined и пытай тех кто его создал".

Судя по тому, как с полями этого типа взаимодействуют формы, поле данного типа содержит идентификаторы записей адресатов в их таблицах, но их больше одного, и само поле не является идентификатором (хотя содержит его).

@Enot
Вы, безусловно, умны, раз имеете такое количество плашек и статус модера, но я постил сюда сообщение не потому, что меня в гугле забанили.

[a33ik]

Цитата:

Сообщение от zloboglot

там отдельные таблицы под сущность - кодгорода, сущность - город, сущность - почтовый индекс

А почему это плохо? В некоторых случаях это очень даже оправдывается.

Цитата:

Сообщение от zloboglot

около 40 полей адреса, заполненное из которых только одно и т д.

По умолчанию к контакту/компании/лиду цепляется по 2 адреса. Полей много, но ничего не поделаешь - таков базовый функционал.

Цитата:

Сообщение от zloboglot

Делали эту базу упоротые наркоманы

Если это стандартный функционал, то, да, наркоманы редкостные - корпорация Майкрософт.

Цитата:

Сообщение от zloboglot

Я не знаю, сделали ли они сами тип данных "список сторон", либо это один из стандартных типов crm.

Есть такая специальная сущность activityparty - как раз через неё такого рода связи и построены. Посмотрите на досуге.

Цитата:

Сообщение от zloboglot

Я не смог за два дня гугления найти инфы по этому поводу ни в рунете, ни в всеобщем.

Странно. Информация по поводу этого точно есть в СДК к системе. Открывали?

Цитата:

Сообщение от zloboglot

Вы, безусловно, умны, раз имеете такое количество плашек и статус модера, но я постил сюда сообщение не потому, что меня в гугле забанили.

Всё справедливо. Артём действительно один из самых талантливых консультантов-разработчиков, которых я знаю.

[Артем Enot Грунин]

Я бы помог вам с запросом, но, к сожалению, сейчас нет доступа к живой системе. Возьмите один из стандартных отчетов по Действиям, загрузите его, откройте в студии и посмотрите как устроен запрос. Ничего особо хитрого вы там не найдете.
Если кратко: есть родительская сущность (таблица) Дествие, есть таблица-перемечение activityparty, в которой указаны сылки на стороны Действия, их тип, и, кажется, поле привязки. Иными словами получается селект аля:
Выбери все действия, на котрые ссылается сторона действия, тип связи которой - пользователь (systemuser) и поле связи - "to", причем systemuserid = {guid}. Как-то так.
Пишу по памяти, так что могу в чем-то ошибаться. В любом случае, как сказал Андрей, информация о том как устроены Действия есть в SDK, так что было бы желание, а разобраться - дело времени.

p.s. В известных мне породах SQL синтаксиса нет конструкций вида атрибут[порядковый номер]. Мой сарказм был обращен на это. Это я к тому, что не стоит сразу обзывать наркоманами тех людей, чей замысел вы не поняли. Вот когда поймете - тогда да, обзывайтесь.

[zloboglot]

за activityparty спасибо. вот, собстно, то, что я нарыл по данному поводу:

имеем класс(таблицу) phonecall, в нем сидит поле to, которое имеет свое значение равным набору активитипать, у активитипать в свою очередь есть поле активитипатяайди.
мсдн говорит следующее по поводу to:

Цитата:

The value of this property is an activityparty array(массив) type.

.
на мсдн даже приведен пример кода:

[C#]
public activityparty[] to {get; set;} //скобочки в шарпах означают массив

судя по всему МСДНу, to - это массив, а значит правильное обращение к айдишнику будет следующим:
phonecall.to[i].activitypartyid

вот только в sql массивов нет, а мне надо по этому полю залинковать звонок с организацией, которой этот звонок идет, причем sql запросом ввиду того что репортбилдер, насколько я знаю, c# код не воспримет.

я собирался писать что-то в духе

select 
 *
from
  phonecalls 
  inner join leads 
  on phonecall.to[0].activitypartyid = lead.leadid

но это, ввиду отсутствия индексации в скьюель, не работало.
правда, я изначально писал phonecall.to[0] = ..., но возможности протестить .activitypartyid нет - удаленный комп лежит мертвым сном (ибо база доступна только из локали)

из разговора с человеком, которому собственно и помогаю - cross join'ы работают криво, т к связки между таблицами есть не везде (а точнее, их почему-то почти нет), и сами таблицы делали непонятно как. Этот же человек мне сообщил, что следует юзать иннерджойны, потому что они работают хотя бы как-то.

Если совсем уж честно, то синтаксис и структуру sql я знаю лишь в общих чертах. знаю про пару видов джойнов, апдейты, делиты и инсерты, и то со словарем в лице гугла. Однако что делать с данной бедой, гугл, к сожалению, не сообщает (либо приводит сэмплы обращений к бд мало того что из шарпа или бейсика, так еще и к базе в файле)

[Артем Enot Грунин]

Вот вы знаете, три раза писал ответ и трижды его стирал... Вам правда повезло, что я не ответил

[a33ik]

Активитипати массив только в объектной модели CRM. Неужели так тяжело посидеть и посмотреть на то как CRM организован со стороны базы? Может пару запросов профайлером снять...
Вот примерный вид запроса для вашего случая:

Select
* From FilteredPhoneCall p
	Inner Join FilteredActivityParty a on p.activityid = a.activityid and a.partyid = <ID of company>