Btrieve и clarion

Clarion, Clarion 7

Модератор: Дед Пахом

Правила форума
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
Developer
Ветеран
Сообщения: 515
Зарегистрирован: 26 Март 2012, 16:18

Btrieve и clarion

Сообщение Developer » 16 Июнь 2019, 23:47

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

С чего это разные названия - хотя при попытке регистрации присутствуют и старые :|
С Уважением, Developer

Аватара пользователя
finsoftrz
✯ Ветеран ✯
Сообщения: 1298
Зарегистрирован: 06 Ноябрь 2014, 12:48

Btrieve и clarion

Сообщение finsoftrz » 08 Июль 2019, 12:19

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

Аватара пользователя
Игорь Столяров
Ветеран движения
Сообщения: 4211
Зарегистрирован: 07 Июль 2005, 9:19
Откуда: г. Ростов-на-Дону

Btrieve и clarion

Сообщение Игорь Столяров » 26 Сентябрь 2019, 8:16

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

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

Аватара пользователя
finsoftrz
✯ Ветеран ✯
Сообщения: 1298
Зарегистрирован: 06 Ноябрь 2014, 12:48

Btrieve и clarion

Сообщение finsoftrz » 26 Сентябрь 2019, 8:43

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

Аватара пользователя
Игорь Столяров
Ветеран движения
Сообщения: 4211
Зарегистрирован: 07 Июль 2005, 9:19
Откуда: г. Ростов-на-Дону

Btrieve и clarion

Сообщение Игорь Столяров » 26 Сентябрь 2019, 8:58

finsoftrz писал(а):
26 Сентябрь 2019, 8:43
Или для наименований в справочниках только первые 10-20 символов.
Понятно, что как-то выкрутиться всегда можно, что в общем-то и делается.
Но осадок и чувство глубокого неудовлетворения происходящим - остаётся.
«V» значит Вендетта !

Аватара пользователя
finsoftrz
✯ Ветеран ✯
Сообщения: 1298
Зарегистрирован: 06 Ноябрь 2014, 12:48

Btrieve и clarion

Сообщение finsoftrz » 26 Сентябрь 2019, 9:06

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

Аватара пользователя
morkovin
Ветеран
Сообщения: 636
Зарегистрирован: 20 Июль 2005, 13:53
Откуда: Volgograd, Russia
Контактная информация:

Btrieve и clarion

Сообщение morkovin » 26 Сентябрь 2019, 9:16

finsoftrz писал(а):
26 Сентябрь 2019, 9:06
ключи с сотнями символов
А если ключ по полю CSTRING, и поле объявлено с запасом по длине? В своё время я отказался от Btrieve именно из-за ограничений по длине ключа, т.к. терялась совместимость dictionary с другими драйверами.
WBR, morkovin

Аватара пользователя
finsoftrz
✯ Ветеран ✯
Сообщения: 1298
Зарегистрирован: 06 Ноябрь 2014, 12:48

Btrieve и clarion

Сообщение finsoftrz » 26 Сентябрь 2019, 9:21

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

Аватара пользователя
Игорь Столяров
Ветеран движения
Сообщения: 4211
Зарегистрирован: 07 Июль 2005, 9:19
Откуда: г. Ростов-на-Дону

Btrieve и clarion

Сообщение Игорь Столяров » 26 Сентябрь 2019, 9:23

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

Аватара пользователя
morkovin
Ветеран
Сообщения: 636
Зарегистрирован: 20 Июль 2005, 13:53
Откуда: Volgograd, Russia
Контактная информация:

Btrieve и clarion

Сообщение morkovin » 26 Сентябрь 2019, 9:32

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

Аватара пользователя
finsoftrz
✯ Ветеран ✯
Сообщения: 1298
Зарегистрирован: 06 Ноябрь 2014, 12:48

Btrieve и clarion

Сообщение finsoftrz » 26 Сентябрь 2019, 9:49

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

Аватара пользователя
Игорь Столяров
Ветеран движения
Сообщения: 4211
Зарегистрирован: 07 Июль 2005, 9:19
Откуда: г. Ростов-на-Дону

Btrieve и clarion

Сообщение Игорь Столяров » 26 Сентябрь 2019, 9:52

finsoftrz писал(а):
26 Сентябрь 2019, 9:49
40 первых символов из наименования товара для упорядочивания в отчетах
В отчётах - прокатит. Но если открывать список товаров для выбора (в режиме SelectRecord), то засветка установится на неправильную запись (при совпадении первых 40 символов в наименовании разных товаров).
«V» значит Вендетта !

kreator
✯ Ветеран ✯
Сообщения: 3412
Зарегистрирован: 28 Май 2009, 14:54
Откуда: Москва

Btrieve и clarion

Сообщение kreator » 26 Сентябрь 2019, 10:06

А как вы решаете проблему уникальности полей при таких напрягах?
We are hard at work… for you. :)

Аватара пользователя
finsoftrz
✯ Ветеран ✯
Сообщения: 1298
Зарегистрирован: 06 Ноябрь 2014, 12:48

Btrieve и clarion

Сообщение finsoftrz » 26 Сентябрь 2019, 10:15

Игорь Столяров писал(а):
26 Сентябрь 2019, 9:52
finsoftrz писал(а):
26 Сентябрь 2019, 9:49
40 первых символов из наименования товара для упорядочивания в отчетах
В отчётах - прокатит. Но если открывать список товаров для выбора (в режиме SelectRecord), то засветка установится на неправильную запись (при совпадении первых 40 символов в наименовании разных товаров).
Для этого и добавляется в ключ второе поле идентификатора записи.
Я хочу сказать, что содержимое в ключе используется только для поиска записей. А не отображения информации. Никто нам не мешает создавать дополнительные поля, предназначенные исключительно для организации эффективного поиска.
Рязань решает.

Аватара пользователя
finsoftrz
✯ Ветеран ✯
Сообщения: 1298
Зарегистрирован: 06 Ноябрь 2014, 12:48

Btrieve и clarion

Сообщение finsoftrz » 26 Сентябрь 2019, 10:17

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

Ответить