ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Обобщенные структуры: Исключающее наследование (физики/юрики )
23 сообщений из 73, страница 3 из 3
  3  все
Обобщенные структуры: Исключающее наследование (физики/юрики )
    #33748292
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4321
Участник
gardenmanМожет быть ситуация когда

ф<ф0
И и>и0
И и>о0

причем запросто...
причем этот вариант - не единственный
мдя. обспешился :0) . простите великодушно. поправимси
так (пользуясь индексом):

ГДЕ
ф<ф0
ИЛИ
((ф = ф0) И (и <и0))
ИЛИ
((ф = ф0) И (и = и0) И (о < о0 ))

или я опять не так вас понял?
...
Рейтинг: 0 / 0
24.05.2006, 13:25
| Ответить | Цитировать | Написать  
Обобщенные структуры: Исключающее наследование (физики/юрики )
    #33748296
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
gardenman Petro123 gardenman2 proposed amendment
Неужели вам не понятно, что быстро найти это невозможно?...
почему нет?
Если кластерный индекс, то ищете нужного и от него шаг вперёд или назад, т.к. кластерный физически упорядочит данные.

Кстати почему вы решили что мне нужна только 1 запись? может я хочу страницу отобразить? а на странице у меня умещается 50 записей?
вы определитесь что вы хоЧите? А то и того, и того, и того.... без потерь не бывает.
FAQ - 4 варианта постраничной выборки
http://www.sql.ru/faq/faq_topic.aspx?fid=105
...
Рейтинг: 0 / 0
24.05.2006, 13:27
| Ответить | Цитировать | Написать  
Обобщенные структуры: Исключающее наследование (физики/юрики )
    #33748318
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gardenman
Участник
2 4321
На самом деле это известная проблема SQL. Вроде есть составной индекс по ФИО а написать выражение WHERE так, чтобы использовать его возможности польностью - невозможно... Поэтому я по-другому решаю эти вещи:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
create table Person (
    fullname varchar( 100 ),
    surname smallint, -- длина фамилии
    name smallint, -- длина имени
    patronimic smallint -- длина отчества
)
create index iPerson on Person (fullname) allow reverse scans

Таким образом fullname содержит сразу все.
Ну, и, естественно вопрос в какой НФ находится эта таблица?...
...
Рейтинг: 0 / 0
24.05.2006, 13:32
| Ответить | Цитировать | Написать  
Обобщенные структуры: Исключающее наследование (физики/юрики )
    #33748326
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gardenman
Участник
>>вы определитесь что вы хоЧите? А то и того, и того, и того.... без потерь не бывает.
Бывает, просо думать надо лучше...

>>FAQ - 4 варианта постраничной выборки
>>http://www.sql.ru/faq/faq_topic.aspx?fid=105
Не в тему...
...
Рейтинг: 0 / 0
24.05.2006, 13:35
| Ответить | Цитировать | Написать  
Обобщенные структуры: Исключающее наследование (физики/юрики )
    #33748378
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
4321 gardenman2 proposed amendment
Неужели вам не понятно, что быстро найти это невозможно?...????

Код: plaintext
1.
Выбрать [перых  1 |]
Не, похоже хочется всех,
где Surname||'#'||Name||'#'||Patronimic = min(Surname||'#'||Name||'#'||Patronimic)
среди Surname||'#'||Name||'#'||Patronimic > 'Иванов#Иван#Иванович'.
например, всех Иванов Иван Иваноффич.
Но что доказывается по теме, по-прежнему не ясно.
...
Рейтинг: 0 / 0
24.05.2006, 13:49
| Ответить | Цитировать | Написать  
Обобщенные структуры: Исключающее наследование (физики/юрики )
    #33748391
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4321
Участник
gardenman2 4321
На самом деле это известная проблема SQL. Вроде есть составной индекс по ФИО а написать выражение WHERE так, чтобы использовать его возможности польностью - невозможно... Поэтому я по-другому решаю эти вещи:таки мой запрос поюзает индекс, но при этом займется внутре себя (пере)сортировкой всех(????) отобранных данных?
тады проблема SQL как языка лишь в том, как написать оператор сравнения строк ROW(a,b,c,...) с использованием индекса (a,b,c,...).


но ведь можно получить то, что вы хотите через курсор,


ЗЫ: или (чуть тормознее) через процедуру вида - если вы так уверены , что в сортировке (из-за недалекости оптимизатора) примут участие все записи, а не по максимум по ~ [1|N] для каждого условия:
SLECT TOP [1|N] * FROM
(SELECT TOP [1|N] *
WHERE ф<ф0
ORDER BY ф DESC, и DESC , о DESC
UNION ALL
SELECT TOP [1|N] *
WHERE ((ф = ф0) AND (и <и0))
ORDER BY ф DESC, и DESC , о DESC
UNION ALL
SELECT TOP [1|N] *
WHERE ((ф = ф0) AND (и =и0) AND (о < о0 )) AS foo
ORDER BY ф DESC, и DESC , о DESC;
...
Рейтинг: 0 / 0
24.05.2006, 13:52
| Ответить | Цитировать | Написать  
Обобщенные структуры: Исключающее наследование (физики/юрики )
    #33748446
Фотография 1024
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
1024
Участник
select persons.*
from persons
join familii on ...
join imena on ...
join otchestva on ...
where
familii.familia='Иванов'
and imena.imya='Иван'
and otchestva.otchestvo='Иванович'

--
шутка. Но будет быстро
...
Рейтинг: 0 / 0
24.05.2006, 14:01
| Ответить | Цитировать | Написать  
Обобщенные структуры: Исключающее наследование (физики/юрики )
    #33748455
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gardenman
Участник
>> проблема SQL как языка лишь в том, как написать оператор сравнения строк ROW(a,b,c,...)
Эт ты прям в точку...
Как бы так вот написать сравнение таким способом, чтоб последующие странения не отрабатывали. Типа встроить предикаты друг в дуруга...
типа

SELECT ... WHERE LT(F,:F,LT(N,:N,LT(P,:P))) ORDER BY F DESC,N DESC, P DESC

было бы круто))... но ..такого нет...
...
Рейтинг: 0 / 0
24.05.2006, 14:02
| Ответить | Цитировать | Написать  
Обобщенные структуры: Исключающее наследование (физики/юрики )
    #33748805
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
gardenmanВроде есть составной индекс по ФИО а написать выражение WHERE так, чтобы использовать его возможности польностью - невозможно...Возможности индекса ? Если допустим TOP, то вполне возможно, хотя непонятно, что означает "полностью". Вот план при поиске следующего((их) - аналогично)

Код: plaintext
1.
2.
3.
4.
5.
6.
StmtText                                                                                                                                                                                                                                                                                                                                    
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 
  |--Nested Loops(Inner Join, OUTER REFERENCES:([t].[Surname], [t].[Name], [t].[Family]))
       |--Top(1)
       |    |--Clustered Index Seek(OBJECT:([tempdb].[dbo].[t].[PK__t__1CF15040]), SEEK:(([t].[Family], [t].[Name], [t].[Surname]) >= ([@Family], [@Name], [@Surname])),  WHERE:(([t].[Name]>=[@Name] AND [t].[Surname]>=[@Surname]) AND (([t].[Family]<>[@Family] OR [t].[Name]<>[@Name]) OR [t].[Surname]<>[@Surname])) ORDERED FORWARD)
       |--Clustered Index Seek(OBJECT:([tempdb].[dbo].[t].[PK__t__1CF15040] AS [t2]), SEEK:([t2].[Family]=[t].[Family] AND [t2].[Name]=[t].[Name] AND [t2].[Surname]=[t].[Surname]) ORDERED FORWARD)

Как видим, Seek по индексу есть, Scan-ов и Sort-ировок не наблюдается.
...
Рейтинг: 0 / 0
24.05.2006, 15:15
| Ответить | Цитировать | Написать  
Обобщенные структуры: Исключающее наследование (физики/юрики )
    #33748859
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gardenman
Участник
2 ChA
Вам же сказано, что писать >= в условиях НЕПРАВИЛЬНО!... так же как и >
НЕТ в SQL стандартной возможности взять предыдущую записть есть упрядочивание идет по нескольким полям сразу...
...
Рейтинг: 0 / 0
24.05.2006, 15:31
| Ответить | Цитировать | Написать  
Обобщенные структуры: Исключающее наследование (физики/юрики )
    #33748962
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
gardenman2 ChA
Вам же сказано, что писать >= в условиях НЕПРАВИЛЬНО!... так же как и >
НЕТ в SQL стандартной возможности взять предыдущую записть есть упрядочивание идет по нескольким полям сразу...Мне ничего не сказано, не надо брать на себя больше, чем можете унести. Лады ? То что считаете Вы, это Ваше личное мнение, не более того.
Насчет неправильности, этот план построен оптимизатором по запросу, который возвращает следующую запись по заданным в переменных значениям полей произвольной записи.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
USE tempdb
GO

CREATE TABLE t (Family varchar( 10 ), Name varchar( 10 ), Surname varchar( 10 ), PRIMARY KEY(Family, Name, Surname))

INSERT INTO t
SELECT 'Иванов', 'Иван', 'Иванович'
UNION ALL SELECT 'Иванов', 'Петр', 'Иванович'
UNION ALL SELECT 'Иванов', 'Петр', 'Семенович'

GO
DECLARE @Family varchar( 10 ), @Name varchar( 10 ), @Surname varchar( 10 )
SELECT @Family = 'Иванов', @Name = 'Петр', @Surname =  'Иванович'

-- Запрос
SELECT ...

GO
DROP TABLE t
Ответ, как надеюсь Вы догадываетесь: 'Иванов', 'Петр', 'Семенович'.
А теперь попробуйте догадаться, что скрыто под "...", можете даже воспользоваться ранее приведеным планом.

P.S. В дальнейшем, просьба, убавить громкость и приводить в качестве доказательств аргументы, а не громкие слова.
...
Рейтинг: 0 / 0
24.05.2006, 15:51
| Ответить | Цитировать | Написать  
Обобщенные структуры: Исключающее наследование (физики/юрики )
    #33749004
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gardenman
Участник
2 ChA
Не получается у меня догадаться.. )
...
Рейтинг: 0 / 0
24.05.2006, 15:59
| Ответить | Цитировать | Написать  
Обобщенные структуры: Исключающее наследование (физики/юрики )
    #33757629
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
To ModelR:
ModelR ShtockНе,электронный адрес надо делать отдельной сущностью,ровно как и почтовый.Я,например,держу их в разных таблицах в первую очередь из-за того,что кол-во полей уж больно разное (У меня в справочнике адресов полей 20,а в эл.адресах-4).
P.S. А причем тут адреса и исключающие наследование :)?
Для сущности Клиент атрибут Основное_средство_связи. Может быть либо почтовым адресом, либо электронным. Если почтовые/электронные адреса - две разные сущности, то как прописывется такая связь?
В системе сделано так: есть таблица Контакт (аналогично таблице Субъект), в которой собраны id всех почтовых и электронных адресов и тип адреса (электронный/почтовый). Соответственно все ссылки в БД идут на эту таблицу.
Сорри-как всегда попутал термины Сущность и Таблица.

To guest_20040621:
guest_20040621В чем принципиальная разница между мобильной связью и стационарной? - типа юмор у меня такой.

А вот на guest_20040621 Отличный пример того, как не следует делать (если, конечно, речь не идет о бд СЗТ). ;)

Не обладая легальным доступом к базе данных оператора, Вы не можете определенно сказать, что телефон 123-12-45 продолжает жить на улице Петрова. Продал владелец квартиру, новый владелец сменил номер телефона, - что, Вы и права собственности на недвижимость в Вашей базе данных регистрируете? ;))

Сеть СЗТ - это приватная сеть. А Вы в Вашей базе данных имитируете ее функционал. Imho абсолютно безосновательно.
отвечу так: я в БД ничего сам не имитирую,а реализую бизнес-требования пользователей имитирующие их видение ситуации.ПМСМ хранение физического места нахождения телефона-нужная вещь.Да,полностью отвечать за достоверность местонахождения телефона не могу,но в случае crm маркетологам лучше знать хоть что-то,чем ничего.Пример для чего это надо:АТС определяет номер звонившего,у девочки на экране пишется что-то типа "вероятный адрес-такой-то".Поэтому после разговора с клиентом в нужный момент (прописанный в инструкции по общению с клиентом) девочка говорит "Вам привезти товар такой-то на Ваш" и называет вероятный адрес. Как показывает статистика (у нас такие замеры проводились)-в 95% адрес доставки совпадает с адресом звонка.А клиенту приятно-думает,что что-то о нем помнят.Раньше был вариант,что говорить адрес по адресу доставки последнего заказа -35% совпадений.Против статистики не попрешь...

P.S. Вышел из отпуска :(,принимаю соболезнования.
...
Рейтинг: 0 / 0
29.05.2006, 11:11
| Ответить | Цитировать | Написать  
Обобщенные структуры: Исключающее наследование (физики/юрики )
    #33757970
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
ShtockНе,электронный адрес надо делать отдельной сущностью,ровно как и почтовый.Я,например,держу их в разных таблицах в первую очередь из-за того,что кол-во полей уж больно разное (У меня в справочнике адресов полей 20,а в эл.адресах-4).
P.S. А причем тут адреса и исключающие наследование :)?
ShtockВ системе сделано так: есть таблица Контакт (аналогично таблице Субъект), в которой собраны id всех почтовых и электронных адресов и тип адреса (электронный/почтовый). Соответственно все ссылки в БД идут на эту таблицу.
Сорри-как всегда попутал термины Сущность и Таблица.
Видимо при этом: Контакт либо Почтовый, либо Электронный, если я правильно понял.
...
Рейтинг: 0 / 0
29.05.2006, 13:07
| Ответить | Цитировать | Написать  
Обобщенные структуры: Исключающее наследование (физики/юрики )
    #33758072
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> я в БД ничего сам не имитирую,а реализую бизнес-требования пользователей

У тупых юзеров нет и не может быть бизнес-требований. По определению.

> хранение физического места нахождения телефона-нужная вещь

Пожалуйста, приведите хотя бы один пример необходимости такой информации.

> crm маркетологам лучше знать хоть что-то,чем ничего

;) Есть разница между "знать" и "догадываться".

> Как показывает статистика

Неправильно поставленная задача исследования - неправильные результаты.

> говорить адрес по адресу доставки последнего заказа

Почему последнего? Что мешает при заказе регистрировать статус адреса доставки? Религия? ;)

Вы делаете принципиальную ошибку: можно _ассоциировать_ телефонный номер с адресом доставки. Причем, абсолютно любой, необязательно стационарного телефона (и не один). Но в корне неверно утверждать, что телефонный номер "живет по такому-то адресу". Разницу замечаете? ;)

Более того, в Вашей базе данных и реализована может быть только и исключительно такая ассоциация. ;))
...
Рейтинг: 0 / 0
29.05.2006, 13:34
| Ответить | Цитировать | Написать  
Обобщенные структуры: Исключающее наследование (физики/юрики )
    #33758118
Фотография proposed amendment
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
proposed amendment
Участник
guest_20040621Разницу замечаете? ;)

просто любопытно - а Вы разницу замечаете?

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

не нужно отметать с порога рассуждения оппонента на том, только, основании, что они расходятся с Вашим мнением.

к чему эти несуразные вопли о тупых юзерах, религии и неверных результатах...

допустим, я могу привести пример, когда анализ номеров телефонов и почтовых адресов на соответствие "места установки"

дает НОВУЮ информацию о покупатели или о поставщике.

да, действительно, между "знать" и "догадываться" существует разница.

Так же как и между "полагать" + "с той или иной степенью уверенности"
...
Рейтинг: 0 / 0
29.05.2006, 13:46
| Ответить | Цитировать | Написать  
Обобщенные структуры: Исключающее наследование (физики/юрики )
    #33758154
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> весьма далекое от истинного положения вещей представление?

Да ну? ;)) Кто, простите, уполномочил Вас выступать от имени истины?

> к чему эти несуразные вопли о тупых юзерах, религии и неверных результатах...

Рассказываю: тупые юзеры _никогда, ни при каких условиях_ не формируют бизнес-требования. Почему тупые? По определению. Других просто не бывает. Религия в данном случае видится единственным оправданием нерациональной структуры данных. Неверные результаты: по предложенной статистике каждый пользователь имеет больше двух адресов доставки и не пользуется мобильной связью. Очевидная чушь.

> я могу привести пример, когда анализ номеров телефонов и почтовых
> адресов на соответствие "места установки"
> дает НОВУЮ информацию о покупатели или о поставщике.

Вы потрудились прочесть то, с чем пытаетесь спорить? Или доминирует желание просто потрепать языком?
...
Рейтинг: 0 / 0
29.05.2006, 13:58
| Ответить | Цитировать | Написать  
Обобщенные структуры: Исключающее наследование (физики/юрики )
    #33758300
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
To ModelR: Так точно.


To guest_20040621:
1. давайте не будем скатываться до дискуссий вида "что первично:бизнес-требования "тупых" пользователей/видение ситуации "мудрым" программистом".Если есть желание поговорить о процессе, то глобальные бизнес-требования (концепция) изначально пораждаются топ-менеджментом (да и то не всегда, обычно все равно ноют "юзера"), а уточняются нелюбимыми юзерами из-за несомненно известного Вам факта "ассиметричности информации" (верхний уровень всегда менее осведомлен о деталях нижнего),но это уж заводите другую тему а-ля "может ли конечный пользователь диктовать требования к системе".
2.пример нужности адреса я Вам привел.Вас он почему-то не удовлетворил.
3.догадка может привести к знаниям,если не хранить ничего - знаний не будет.
4.почитайте о сути crm - поймете,что о клиенте надо хранить практически все,чтобы повысить его лояльность
5. <Более того, в Вашей базе данных и реализована может быть только и исключительно такая ассоциация. ;))> -люблю провидцев :))

P.S.Кстати,каждый из нас пользователь.Вы же пользователь MS Internet Explorer/Mozzila или какого-либо другого броузера.Он был создан для удовлетворения Ваших потребностей.Значит ли это,что Вы тупой?Вряд ли... Так что давайте без лозунгов...
...
Рейтинг: 0 / 0
29.05.2006, 14:35
| Ответить | Цитировать | Написать  
Обобщенные структуры: Исключающее наследование (физики/юрики )
    #33758344
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> давайте не будем скатываться

Если какое-то утверждение может быть понято неправильно, оно будет понято неправильно. ;) Пофиг интеллект юзеров, это не их работа - генерировать бизнес-требования. Это все, что я хотел сказать.

> пример нужности адреса я Вам привел

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

> если не хранить ничего - знаний не будет

Ваша фамилия, насколько я понимаю, не Шуклин, - давайте не будем опускаться до демагогии.

> почитайте о сути crm

;) Что именно почитать?

> о клиенте надо хранить практически все,чтобы повысить его лояльность

Разочарую: CRM - это всего лишь инструмент политики предприятия, а не панацея. ;) "Все" хранить не только невозможно, но и бессмысленно.

> -люблю провидцев :))

Напрасно ерничаете. ;)

> Вы же пользователь MS Internet Explorer/Mozzila

Firefox, естественно.

> Он был создан для удовлетворения Ваших потребностей.

В том числе. Но это не значит, что мне вменяется в обязанность поддерживать какой-то из разделов технического задания.
...
Рейтинг: 0 / 0
29.05.2006, 14:49
| Ответить | Цитировать | Написать  
Обобщенные структуры: Исключающее наследование (физики/юрики )
    #33758458
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
0.инструмент политики предприятия - не crm,а ориентированность на маркетинг.crm-инструмент маркетинга.но это так, словоблудие...
1. определение CRM
2. по поводу хранения "всего" сведу все к любимой песне: заинтересованные в использовании системы люди хотят видеть максимальное количество структурированной информации по клиентам в целях ее анализа. Мы им это обеспечиваем.Панацея ли это или нет решать не мне.Я системный аналитик,а не специалист по внедрению методологии crm в рамках развития маркетинга на предприятии.

P.S. А топик то о "физиках/юриках"...
...
Рейтинг: 0 / 0
29.05.2006, 15:28
| Ответить | Цитировать | Написать  
Обобщенные структуры: Исключающее наследование (физики/юрики )
    #33758569
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> 0.

Первое техническое задание на CRM-подобную софтину я писал десять лет назад (тогда еще и термина такого не было; да и Сеть была сильно проще и сильно меньше). ;)) Полагаете, сможете рассказать мне что-то новое о CRM? ;))

> инструмент политики предприятия - не crm,а ориентированность на
> маркетинг

Снова огорчу. ;) Не бывает "ориентированности на маркетинг". Долго рассказывать, почему, просто поверьте на слово. ;)

> максимальное количество структурированной информации

Отличная фраза. Можно вопросы? ;)

Что такое информация (я читал Шеннона; интересно, что Вы в данном случае под этим понимаете)?
Что есть функция количества информации и как Вы понимаете ее экстремумы?

> Мы им это обеспечиваем.

Рад слышать. ;)

> Я системный аналитик

Да, я помню. ;) Мне думается, что системный аналитик должен более строго относиться к терминологии, - собственно флейм по этому поводу. Полагаю, с природой хранящихся в Вашей базе данных фактов мы разобрались. ;)

> А топик то о "физиках/юриках"...

;) А что с ними не так? Все остались при своих, что можно было предположить с самого начала. Я что-то неправильно понял?
...
Рейтинг: 0 / 0
29.05.2006, 15:59
| Ответить | Цитировать | Написать  
Обобщенные структуры: Исключающее наследование (физики/юрики )
    #33758656
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
1.вот по поводу "Не бывает "ориентированности на маркетинг". Долго рассказывать, почему, просто поверьте на слово. ;)" - говорить можно много и долго.Главное определиться со словом "маркетинг", но это я думаю уже в другом топике, да и в другой ветке.Если есть желание поговорить - пишите в "ERP" - там поговорим.
2.под максимальным количеством информации о клиенте в случае crm я понимаю то подмножество фактов(грубо говоря - сделка с клиентом-факт) и атрибутов клиента(или свойств),которое необходимо и достаточно для построения максимально возможного количества видов отчетов маркетолога и оперативной поддержки сотрудников фронт-офиса (неважно где он сделан-в отдельном программном обеспечении или в самой crm-системе). Понятно,что грубо говоря для построения "воронки продаж" достаточно хранения фактов звонков клиента и факта сделки,но это один из самых простых отчетов,а виды отчетов уже определены заинтересованными лицами.
...
Рейтинг: 0 / 0
29.05.2006, 16:22
| Ответить | Цитировать | Написать  
Обобщенные структуры: Исключающее наследование (физики/юрики )
    #33758723
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> подмножество фактов(грубо говоря - сделка с клиентом-факт)
> и атрибутов клиента(или свойств),которое необходимо и достаточно
> для построения максимально возможного количества видов отчетов
> маркетолога и оперативной поддержки сотрудников фронт-офиса

Еще одна хорошая фраза. ;) ОК, не буду больше ничего спрашивать. Консенсус. При случае обязательно вернемся к теме.
...
Рейтинг: 0 / 0
29.05.2006, 16:42
| Ответить | Цитировать | Написать  
23 сообщений из 73, страница 3 из 3
  3  все
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Обобщенные структуры: Исключающее наследование (физики/юрики )
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&msg=33748318&tid=1545233]:
 0ms
get settings:
 6ms
get forum list:
 14ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 151ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 60ms
get tp. blocked users:
 1ms
others: 204ms
total:  454ms
созд. / загр.: 454ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]