Переключение на Главную Страницу Страницы: 1 [2]  ОтправитьПечать
Очень популярная тема (более 25 ответов) Множественный фильтр ИТЗ (число прочтений - 8388 )
Strannik
Junior Member
**
Отсутствует


Оцифрованный романтик

Сообщений: 29
Местоположение: Где-то в Башкирии
Зарегистрирован: 17. Июня 2011
Пол: Мужской
Re: Множественный фильтр ИТЗ
Ответ #15 - 13. Июля 2011 :: 21:31
Печать  
kms писал(а) 13. Июля 2011 :: 20:26:
Было не совсем строго и можно было трактовать неверно.
Все равно, на мой взгляд, несколько сложновато для восприятия


Рад, что Вам так же весело, как и мне! Особенно понравилась конструкция "несколько сложновато"...  Улыбка

Только вот какая штука. Вы сразу ОЧЕНЬ правильно поставили соответствие составного индекса ИТЗ композитному индексу SQL. Но сущность композитного индекса SQL есть конкатенация значений, входящих в индекс. Точнее, их строковых представлений. Это раз. Обязательным условием композитного индекса SQL является наличие значений всех полей, входящих в определение индекса - это два.

http://alexey.raga.name/post/2011/06/25/sql-fts-composite-key.aspx

http://doc.prototypes.ru/database/postgresql/indexes/composite/

http://www.lred.ru/index.php/bd/830--------sql

http://www.1cpp.ru/forum/YaBB.pl?num=1227685716/46

http://vlads.tom.ru/index.php?option=com_content&view=article&catid=18%3Apostgre...

Т.е. технически я могу создать новую колонку с конкатенацией тех трех полей (ведь мы всегда так и поступали в родной ТаблицеЗначений от 1С) и получу интересующий меня результат.

Исходя из этого, утверждение "X < Y тогда и только тогда, когда существует такое k из [1, n], что для любого i из [1, k] выполняется Xi < Yi" уже не соответствует определению технологии фильтрации по композитному индексу, именно в части "существует такое k из [1, n], что для любого i из [1, k]", так как позволяет рассматривать МЕНЬШЕЕ количество значений полей, чем количество полей, входящих в индекс. Вот это описание я бы назвал "нестрогим", даже "фривольным" по отношению к композитному индексу...  Улыбка

Особенностью реализации в ICPP является то, что, даже если принять Вашу новую доктрину за основу, то в случаях, когда f1<>F1, значение k, а, соответственно, и i ВСЕГДА равно 1 для любого n; когда f1=F1 и f2<>F2, значение k, а, соответственно, и i ВСЕГДА равно 2 для любого n; и т.д., что уже само по себе подозрительно!

Ну и уж такое изящное новое описание СОВЕРШЕННО не соответствует индексу-конкатенации.

Увы, Ваше первое описание не было "нестрогим", наоборот было абсолютно строгим и соответствовало работе композитного ключа SQL и данному мною представлению о работе составного индекса ИТЗ.

А дуэль? Это не связано с "состязательным полем" (а почему бы и нет, собственно?), а связано, мягко говоря, с не очень корректными определениями в мой адрес. Ну надо же мне было как-то отреагировать на "утверждение, причем неверное"...  Улыбка

Достаточно было посидеть и понажимать кнопочки в отправленной мною обработке - ведь я уже все сделал, стоило только проверить... И, возможно, не было бы этих "определений".
  

Когда я сомневаюсь - спрошу, если есть у кого.&&Если меня не устроит ответ - я разбираюсь сам.&&Если некого спросить - я разбираюсь сам.&&Если я разберусь - я перестаю сомневаться.
Наверх
 
IP записан
 
Satans Claws
God Member
*****
Отсутствует


1C++ rocks!

Сообщений: 721
Зарегистрирован: 29. Ноября 2010
Re: Множественный фильтр ИТЗ
Ответ #16 - 14. Июля 2011 :: 03:42
Печать  
Цитата:
Но сущность композитного индекса SQL есть конкатенация значений, входящих в индекс. Точнее, их строковых представлений.


А пацаны-то не знают...

Хочешь сказать, что скулевый индекс по полям {f1 numeric(19, 3), f2 char(10), f3 numeric(19,3)} будет сформирован через строковые представления?
Ну, на тебе 2 строки данных:
{2.25, "а", 7.32}
{100.3, "б", 4.55}
  
Наверх
 
IP записан
 
Strannik
Junior Member
**
Отсутствует


Оцифрованный романтик

Сообщений: 29
Местоположение: Где-то в Башкирии
Зарегистрирован: 17. Июня 2011
Пол: Мужской
Re: Множественный фильтр ИТЗ
Ответ #17 - 14. Июля 2011 :: 03:56
Печать  
Satans Claws писал(а) 14. Июля 2011 :: 03:42:
Цитата:
Но сущность композитного индекса SQL есть конкатенация значений, входящих в индекс. Точнее, их строковых представлений.


Хочешь сказать, что скулевый индекс по полям {f1 numeric(19, 3), f2 char(10), f3 numeric(19,3)} будет сформирован через строковые представления?
Ну, на тебе 2 строки данных:
{2.25, "а", 7.32}
{100.3, "б", 4.55}


Если это вопрос, то вот ответ в нотации 1С:

Format(Field1,"N19.3")+Left(Field2+"          ",10)+Format(Field3,"N19.3")

Физически это будет выглядеть так:

.               2.25а                       7.32
.             100.3 б                       4.55


В рекомендациях по построению композитного ключа СПЕЦИАЛЬНО оговаривается, что длина ключа будет равна сумме длин составляющих. Потому максимальное количество полей в Borland Interbase, например, ограничено числом 16!

Satans Claws писал(а) 14. Июля 2011 :: 03:42:
Цитата:
Но сущность композитного индекса SQL есть конкатенация значений, входящих в индекс. Точнее, их строковых представлений.


А пацаны-то не знают...


Ну, это проблема "пацанов"...  Улыбка
  

Когда я сомневаюсь - спрошу, если есть у кого.&&Если меня не устроит ответ - я разбираюсь сам.&&Если некого спросить - я разбираюсь сам.&&Если я разберусь - я перестаю сомневаться.
Наверх
 
IP записан
 
Z1
God Member
*****
Отсутствует


I Love YaBB 2!

Сообщений: 2906
Местоположение: Москва
Зарегистрирован: 26. Мая 2006
Пол: Мужской
Re: Множественный фильтр ИТЗ
Ответ #18 - 14. Июля 2011 :: 04:15
Печать  
(Strannik)

Цитата:
Но сущность композитного индекса SQL есть конкатенация значений, входящих в индекс.
Точнее, их строковых представлений. Это раз.
Обязательным условием композитного индекса SQL является наличие значений всех полей,
входящих в определение индекса - это два.

первое утверждение для MS SQL не верно ( ну а далее основываясь на ложных
аксиомах Вы однозначно приходите к ложным выводам ).

Конкатенация может расматриваться как модель для понимания явления но не как
эквивалентна составному индексу.

пусть есть
create table t(
f1 varchar(2),
f2 varchar(2)
)

insert into t(f1,f2) values ('1','11')
insert into t(f1,f2) values ('11','1')

Конкатенация значений на каждой из этих строк равна '111'
А если построить составной индекс то значения  индексов для этих строк будут разные.

  
Наверх
 
IP записан
 
Z1
God Member
*****
Отсутствует


I Love YaBB 2!

Сообщений: 2906
Местоположение: Москва
Зарегистрирован: 26. Мая 2006
Пол: Мужской
Re: Множественный фильтр ИТЗ
Ответ #19 - 14. Июля 2011 :: 04:16
Печать  
тоже самое ошибочное заключение
Цитата:
Т.е. технически я могу создать новую колонку с
конкатенацией тех трех полей
(ведь мы всегда так и поступали в родной ТаблицеЗначений от 1С)
и получу интересующий меня результат.

Если Вы никогда не сталкивались с труднообнаруживаемыми
ошибками в ( своих или чужих) программах основаных на этом тезесе
то Вам очень повезло.

На самом деле если речь о ТЗ то доп колонку надо создавать как-то так.
Считаем что в ТЕстовых значениях не может быть символа '$'
Тогда на роль индекса подходит колонка
СокрЛП(ТЗ.Колонка1) + "$" + СокрЛП(ТЗ.Колонка2) + "$" + СокрЛП(ТЗ.Колонка3)

ИТЗ позволяет не городить этого огорода .




  
Наверх
 
IP записан
 
Z1
God Member
*****
Отсутствует


I Love YaBB 2!

Сообщений: 2906
Местоположение: Москва
Зарегистрирован: 26. Мая 2006
Пол: Мужской
Re: Множественный фильтр ИТЗ
Ответ #20 - 14. Июля 2011 :: 04:19
Печать  
По поводу второго утверждения из (15) мысль как то не очень понятно.
Применительно 1с77 ms sql  1csql таблицы  не могут содержать NULL значений.
Составной индекс (N полей)  может рассматриваться ms sql сервером кандидатом для индекса
плана выполнения если
в условие where присутстуют точные значения всех
левых  K велечин ( Важно 1 <= К <= N )
  
Наверх
 
IP записан
 
Satans Claws
God Member
*****
Отсутствует


1C++ rocks!

Сообщений: 721
Зарегистрирован: 29. Ноября 2010
Re: Множественный фильтр ИТЗ
Ответ #21 - 14. Июля 2011 :: 05:56
Печать  
Z1 писал(а) 14. Июля 2011 :: 04:16:
тоже самое ошибочное заключение
На самом деле если речь о ТЗ то доп колонку надо создавать как-то так.
Считаем что в ТЕстовых значениях не может быть символа '$'
Тогда на роль индекса подходит колонка
СокрЛП(ТЗ.Колонка1) + "$" + СокрЛП(ТЗ.Колонка2) + "$" + СокрЛП(ТЗ.Колонка3)

ИТЗ позволяет не городить этого огорода .



но ты же понимаешь, что символ "$" имеет свой вес в сортировки строки, и результат будет неверным.
Вот есть вместо символа "$" в предположении использовать символ #255 - то оно уже становится более правильным (при условии, что у нас не юникод).
  
Наверх
 
IP записан
 
Z1
God Member
*****
Отсутствует


I Love YaBB 2!

Сообщений: 2906
Местоположение: Москва
Зарегистрирован: 26. Мая 2006
Пол: Мужской
Re: Множественный фильтр ИТЗ
Ответ #22 - 14. Июля 2011 :: 06:10
Печать  
Satans Claws писал(а) 14. Июля 2011 :: 05:56:
Z1 писал(а) 14. Июля 2011 :: 04:16:
тоже самое ошибочное заключение
На самом деле если речь о ТЗ то доп колонку надо создавать как-то так.
Считаем что в ТЕстовых значениях не может быть символа '$'
Тогда на роль индекса подходит колонка
СокрЛП(ТЗ.Колонка1) + "$" + СокрЛП(ТЗ.Колонка2) + "$" + СокрЛП(ТЗ.Колонка3)

ИТЗ позволяет не городить этого огорода .



но ты же понимаешь, что символ "$" имеет свой вес в сортировки строки, и результат будет неверным.
Вот есть вместо символа "$" в предположении использовать символ #255 - то оно уже становится более правильным (при условии, что у нас не юникод).


Все равно какой использовать доп символ главное чтобы он не применялся в строках.
Речь идет не о сортировке по этому специндексу ТЗ
а о поиске значений по  этому специндексу  в ТЗ.
(если нужа сортировка то можно
просто ТЗ.Сортировать("Колонка1,Колонка2,Колонка3");   )
  
Наверх
 
IP записан
 
ADirks
1c++ developer
1c++ moderator
Отсутствует


А нужны ли мы нам?

Сообщений: 692
Местоположение: Новосибирск
Зарегистрирован: 22. Мая 2006
Пол: Мужской
Re: Множественный фильтр ИТЗ
Ответ #23 - 14. Июля 2011 :: 06:11
Печать  
Чиста поржать

Код
Выбрать все
int numeric_compare(int a, int b)
{
	return a - b;
}

int cv_numeric_compare(CValue& left, CValue& right)
{
	return left.GetNumeric().Compare(right.GetNumeric());
}

int string_compare(LPCSTR left, LPCSTR right, TVTIndexDescrRecord const& IdxRec)
{
	if( IdxRec.NoCaseStringCompare )
	{
		if( IdxRec.TrimStrings )
			return FastCompareNoCase.CompareTrimSpc(left, right);
		else
			return FastCompareNoCase.Compare(left, right);
	}
	else if ( IdxRec.TrimStrings )
		return FastCompare.CompareTrimSpc(left, right);
	else
		return FastCompare.Compare(left, right);
}

int cv_string_compare(CValue& left, CValue& right, TVTIndexDescrRecord const& IdxRec)
{
	return string_compare((LPCSTR)CString(left.Format()), (LPCSTR)CString(right.Format()), IdxRec);
}

int date_compare(CDate const& d1, CDate const& d2)
{
	int comp_res = numeric_compare(d1.GetYear(), d2.GetYear());
	if( comp_res ) return comp_res;
	comp_res = numeric_compare(d1.GetMonth(), d2.GetMonth());
	if( comp_res ) return comp_res;
	comp_res = numeric_compare(d1.GetMonthDay(), d2.GetMonthDay());
	return comp_res;
}

int time_compare(CEventTime const& t1, CEventTime const& t2)
{
	if( t1 < t2 ) return -1;
	else if( t1 > t2 ) return 1;
	return 0;
}

inline DWORD gettypeid(CValue const &cv)
{
	return cv.m_mdid ? cv.m_mdid : cv.ValTypeID;
}

int inner_compare(CValue &left, CValue &right)
{
	int diff;
	if( !(diff = gettypeid(left) - gettypeid(right)) )
	{
		if( !(diff = left.m_ObjID.GetlObjID() - right.m_ObjID.GetlObjID()) )
			diff = FastCompare.Compare(left.m_ObjID.DBSign.Sign, right.m_ObjID.DBSign.Sign);
	}
	return diff;
}


int CValue_compare(CValue &left, CValue &right, TVTIndexDescrRecord const& IdxRec)
{
	int nTypeCodeLeft = left.GetTypeCode();
	int nTypeCodeRight = right.GetTypeCode();
	if( nTypeCodeLeft == nTypeCodeRight )
	{
		switch( nTypeCodeLeft )
		{
		case UNDEFINE_TYPE_1C:
			return 0;
			break;
		case NUMBER_TYPE_1C:
			return cv_numeric_compare(left, right);
			break;
		case STRING_TYPE_1C:
			return string_compare(left.m_String.operator LPCSTR(), right.m_String.operator LPCSTR(), IdxRec);
			break;
		case DATE_TYPE_1C:
			{
				CDate &d1 = left.GetDate(), &d2 = right.GetDate();
				return date_compare(d1, d2);
			}
			break;
		case REFERENCE_TYPE_1C:
			{
				if( IdxRec.CompareType == CmpByInnerRepr )
					return inner_compare(left, right);

				// учтено время жизни указателей
				int comp_res = cv_string_compare(left, right, IdxRec);
				if( comp_res == 0 )
					comp_res = inner_compare(left, right);

				return comp_res;
			}
			break;
		case DOCUMENT_TYPE_1C:
			if( IdxRec.CompareType == CmpByInnerRepr )
			{
				return inner_compare(left, right);
			}
			else
			{
				CDate d1(0,0,0), d2(0,0,0);
				CEventTime t1, t2;
				GetDateTimeFromValue(left, d1, t1);
				GetDateTimeFromValue(right, d2, t2);
				int comp_res = date_compare(d1, d2);
				if( comp_res == 0 ) comp_res = time_compare(t1, t2);
				return comp_res;
			}
			break;

		case AGREGATE_TYPE_1C:
			{
				if( IdxRec.CompareType == CmpByInnerRepr )
					return left.m_Context - right.m_Context;

				int comp_res = cv_string_compare(left, right, IdxRec);
				if( comp_res == 0 )
					comp_res = left.m_Context - right.m_Context;

				return comp_res;
			}
			break;

		default:
			if( IdxRec.CompareType == CmpByInnerRepr )
				return inner_compare(left, right);
			else
				return cv_string_compare(left, right, IdxRec);
		}
	}
	else
	{
		return numeric_compare(nTypeCodeLeft, nTypeCodeRight);
	}
}

int CVTIndexRecord::compare(CVTIndexRecord& RightRecord)
{
	int sz = IndexFields->size();
	for( int i = 0; i < sz; i++ )
	{
		int comp_res;
		TVTIndexDescrRecord &IdxRec = IndexFields->operator[](i);

		CValue &left = Row->GetValue(IdxRec.ColumnNumber);
		CValue &right = RightRecord.Row->GetValue(IdxRec.ColumnNumber);

/*
		try{
			comp_res = CValue_compare(left, right, IdxRec);

		} catch(...)
		{
			RuntimeError("Ошибка памяти при сравнении строк в индексе. rows: %p vs %p; values: %p vs %p",
				Row, RightRecord.Row, &left, &right);
		}

		if( comp_res != 0 ) return comp_res * IdxRec.Direction;
*/
		comp_res = CValue_compare(left, right, IdxRec);
		if (comp_res)
		{
			if (IdxRec.Direction < 0)
				comp_res =-comp_res;

			return comp_res;
		}
	}

	return 0;
}

 



Этот фрагмент отвечает на все вопросы, затронутые тут.
И я не думаю, что хоть один вменяемый программист станет преобразовывать числа в строки для сравнения.
  
Наверх
 
IP записан
 
Satans Claws
God Member
*****
Отсутствует


1C++ rocks!

Сообщений: 721
Зарегистрирован: 29. Ноября 2010
Re: Множественный фильтр ИТЗ
Ответ #24 - 14. Июля 2011 :: 06:12
Печать  
Z1, Условие на подмножество (по индексу) невозможно без сортировки.
  
Наверх
 
IP записан
 
Salimbek
God Member
*****
Отсутствует



Сообщений: 862
Зарегистрирован: 06. Июня 2006
Пол: Мужской
Re: Множественный фильтр ИТЗ
Ответ #25 - 14. Июля 2011 :: 06:20
Печать  
Strannik писал(а) 14. Июля 2011 :: 03:56:
Физически это будет выглядеть так:

.               2.25а                       7.32
.             100.3 б                       4.55


Ответь, теперь, будет ли в эти границы входить значение
.               7.25я                       7.32
UPD.
то же самое в виде строки данных:
{7.25, "я", 7.32}
Напомню (чтобы не листать вверх), что диапазон был задан следующими строками данных:
{2.25, "а", 7.32}
{100.3, "б", 4.55}
  
Наверх
ICQ  
IP записан
 
kms
1c++ power user
1c++ moderator
Отсутствует


я хочу, чтоб сюда проложили
дорогу оттуда...

Сообщений: 4632
Зарегистрирован: 19. Мая 2006
Re: Множественный фильтр ИТЗ
Ответ #26 - 14. Июля 2011 :: 12:12
Печать  
[quote author=Ezerrow link=1310144573/0#8 date=1310563994]
Составной индекс НЕ ДОЛЖЕН НИЧЕМ отличаться от композитных индексов SQL (выражение "не отличается принципиально" дает некоторую свободу интерпретации)...
[/quote]
Изначально неверное утверждение.

[quote]
Вы сразу ОЧЕНЬ правильно поставили соответствие составного индекса ИТЗ композитному индексу SQL. Но сущность композитного индекса SQL есть конкатенация значений, входящих в индекс. Точнее, их строковых представлений.
[/quote]
Неверное утверждение.

[quote]
Обязательным условием композитного индекса SQL является наличие значений всех полей, входящих в определение индекса - это два.
[/quote]
Утверждение, не имеющее отношения к ИТ.
Плюс крайне слабая и потому бессмысленная формулировка.
Наличие значений где? В таблице? В предложении WHERE?
Для каких реализаций SQL? К примеру, MSSQL не накладывает подобных ограничений ни на значения в таблице, ни на значения в предложении WHERE.

И т.д.
Надо продолжать?

[quote author=kms link=1310144573/0#14 date=1310588803]А дуэль? Это не связано с "[i]состязательным полем[/i]" (а почему бы и нет, собственно?), а связано, мягко говоря, с не очень корректными определениями в мой адрес. Ну надо же мне было как-то отреагировать на "[i]утверждение, причем неверное[/i]"...  :)
[/quote]
Если еще не понятно, я поясню: нет состязательного логического поля - это означает что мне не понятно, как можно опровергать голословные утверждения, высказанные в абсолютном стиле (см. первый абзац).

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

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

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

De quelle planète es-tu?
Наверх
 
IP записан
 
Переключение на Главную Страницу Страницы: 1 [2] 
ОтправитьПечать