forum.clarionlife.net

Игорь Столяров писал(а): ↑16 Июнь 2019, 23:43Как скажете … В C11 почему-то используется историческое название этой БД …

Так и думал

С чего это разные названия - хотя при попытке регистрации присутствуют и старые

Прошел месяц с начала работы на actian zen в боевом режиме. Пока особых вопросов не возникало. База без лога 13+ ГГб. Деревья в медгородке все обстучал...
Из нюансов относительно работы с tps есть еще такой. Если используется режим разбивки таблицы на физические файлы по 2ГБ, то при автоконвертации структуры базы данных надо копировать все части на место старых. То есть требуется небольшая правка шаблона.

Вот всем хорош Btrieve, особенно в контексте использования c Clarion.
Но даёт о себе знать его ископаемое нутро ...

Ограничение на суммарную длину полей в ключах 256 байт неприемлемо в 2019 г.
Пара-тройка полей с GUID и всё, наименование уже не помещается.

Сделайте одно поле с guid, а остальное фильтруйте. Я придерживаюсь мнения, что в ключах не должно быть длинных строковых полей. Например, вместо 150 символов алкогольной марки в ключе можно сохранять только последние 10, которые редко будут повторяться. Или для наименований в справочниках только первые 10-20 символов.

finsoftrz писал(а): ↑26 Сентябрь 2019, 8:43Или для наименований в справочниках только первые 10-20 символов.

Понятно, что как-то выкрутиться всегда можно, что в общем-то и делается.
Но осадок и чувство глубокого неудовлетворения происходящим - остаётся.

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

finsoftrz писал(а): ↑26 Сентябрь 2019, 9:06ключи с сотнями символов

А если ключ по полю CSTRING, и поле объявлено с запасом по длине? В своё время я отказался от Btrieve именно из-за ограничений по длине ключа, т.к. терялась совместимость dictionary с другими драйверами.

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

finsoftrz писал(а): ↑26 Сентябрь 2019, 9:06чувство удивления вызывают ключи с сотнями символов

Понимаете, построение ключей - это же не самоцель. Структура БД (в т.ч. ключи) описывает некую существующую реальность.
Например в том же Меркурии не заморачиваются сильно и почти все символьные наименования по 255 символов.
А чего думать-то ? Любить - так королеву. Можно конечно это всё подрезать исходя из здравой логики и технологических ограничений.
И потом молится, что бы это где-то не вылезло. У меня уже вылезло, когда один дебил (другого слова нет) указал наименование
своих хинкали в 212 символов …

finsoftrz писал(а): ↑26 Сентябрь 2019, 9:21для чего этот ключ нужен

На собственном опыте:
Было поле CSTRING(120) и по нему ключ. Через год попросили увеличить да 250. Ещё через пару лет до 512 и т.д.
Вот типичное наименование дисциплины "МДК 01.03 Сестринское дело в системе первичной медико-санитарной помощи населению".
А вот краткое наименование "МДК01.03 СД в СПМСПН". Что здесь можно понять?

Краткое наименование только в ключе. Выводится полное. У меня потребность в длинных ключах была только в справочнике товаров. 40 первых символов из наименования товара для упорядочивания в отчетах и ид для функции четкого поиска в стандартном броузе. Решается объявлением второго поля в таблице с атрибутом over на поле с полным наименованием. Все отлично работает и в tps, и в btrieve.

finsoftrz писал(а): ↑26 Сентябрь 2019, 9:4940 первых символов из наименования товара для упорядочивания в отчетах

В отчётах - прокатит. Но если открывать список товаров для выбора (в режиме SelectRecord), то засветка установится на неправильную запись (при совпадении первых 40 символов в наименовании разных товаров).

А как вы решаете проблему уникальности полей при таких напрягах?

Игорь Столяров писал(а): ↑26 Сентябрь 2019, 9:52

finsoftrz писал(а): ↑26 Сентябрь 2019, 9:4940 первых символов из наименования товара для упорядочивания в отчетах

В отчётах - прокатит. Но если открывать список товаров для выбора (в режиме SelectRecord), то засветка установится на неправильную запись (при совпадении первых 40 символов в наименовании разных товаров).

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

kreator писал(а): ↑26 Сентябрь 2019, 10:06А как вы решаете проблему уникальности полей при таких напрягах?

Напряги только в головах...