forum.clarionlife.net

Ага. Т.е. похоже, что связь между описанием ключа в словаре и индексом в БД Firebird устанавливается по какому-то внутреннему коду ...
Понятно, что для списков Clarion желательно наличие уникального ключа, но это ведь может быть и просто уникальное наименование ....

Спасибо ! А вот еще такой детский вопрос. Я создал IBExpert новую (пустую) БД Firebird.
Хочу просто к ней подключится и выполнить, например "CREATE TABLE ...".
Это можно сделать ? Или нужно обязательно, что бы был файл и уже после его открытия
действовать через File{Prop:SQL} = "CREATE TABLE ..." ?

Я не туплю. Нашел хорошее русское описание, заказал на озоне книжку по Firebird, разбираюсь.
Но есть вопросы, которые специфичны для связки Clarion - ODBC - Firebird. Спасибо !

kreator писал(а): А в самой базе такого ключа быть не должно.

Лучше написать "может не быть".

kreator писал(а): есть мнение, что большое количество индексов в БД ухудшает быстродействие

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

Игорь Столяров писал(а):то можно сделать ? Или нужно обязательно, что бы был файл и уже после его открытия
действовать через File{Prop:SQL} = "CREATE TABLE ..." ?

Если есть в БД хоть какой-нибудь файл, то должно покатить. Насчёт открытия этого файла не могу точно ответить, точно, если к неоткрытому файлу сделать запрос "Select ...", а потом Next(), то будет ошибка (неоткрытие файла).
Я всё же не очень понимаю нужду создавать структуру БД запросами.

Shur писал(а): kreator писал(а):
Источник цитаты А в самой базе такого ключа быть не должно.


Лучше написать "может не быть".

Не, ну создавать индекс "Name, ID" - это чересчур. Зачем?

kreator писал(а): Я всё же не очень понимаю нужду создавать структуру БД запросами.

Я просто привел как пример команду создания таблицы ... Это может быть "ALTER DATABASE SET LINGER 30" или
запуск хранимой процедуры, которая создаст таблицы ....
Т.е. можно выполнить команду из приложения без подключения к (наличия) таблицы в базе Firebird ?

kreator писал(а): Не, ну создавать индекс "Name, ID" - это чересчур. Зачем?

Ну ежели вопрос задан... Не знаю, как там в других реализациях, а в MS SQL, если бы выбирать между просто индексом по полю Name и этим я бы именно такой индекс и посоветовал построить.
Потому как индекс получился бы по определению уникальным. По этой причине он бы имел меньший размер ключа на корневом и промежуточных уровнях. Плюс вы наверняка захотите связать эту таблицу с какой-либо ещё по полю ID. В этом случае сиквелу даже не придётся лезть в саму запись -- ID уже известен.

1. Насчет ключей. Достаточно одного уникального. Акцесс, например, при создании таблицы сам впендюривает поле UID и удалить его низя. Хотя м.б. сейчас уже можно. Давно я с ним не работал.
Порядок выбора и сортировки определяется SELECT-ом
2. Чем мне нравится работать с SQL-ными базами - это никаких Open (Close). Connect ......... Disconnect. А в том месте, где стоят точки делай, что хочешь (в разумных пределах) создавай, удаляй, модифицируй.

Игорь Столяров писал(а):Т.е. можно выполнить команду из приложения без подключения к (наличия) таблицы в базе Firebird ?

Провёл эксперимент. Всё нормально. pro:SQL можно применить и к несуществующей таблице.

Shur писал(а):Потому как индекс получился бы по определению уникальным.

А зачем такая уникальность. Для первичного ключа нужен ID только. А если нужна уникальность Name, то индекс только по Name.

kreator писал(а): А зачем такая уникальность. Для первичного ключа нужен ID только. А если нужна уникальность Name, то индекс только по Name.

Перечитай внимательно. Для MS SQL -- меньший размер ключа. Это я про физику организации индексов в MS SQL.
И маленький нюанс: уникальный сам по себе индекс по Name+ID не даёт уникальности по Name. Так что для модели данных ничего не меняется кроме того, что индекс получается более оптимизированным.

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

Ошибся, видимо надо...

gromov писал(а): 1. Насчет ключей. Достаточно одного уникального.

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

kreator писал(а): Всё нормально. pro:SQL можно применить и к несуществующей таблице.

Спасибо, стало светлее ... Работаем !
Вообще ощущение от работы с Firebird - как-то все просто и понятно, все находится там где ожидаешь это увидеть
и работает так, как должно работать (в отличии от MS SQL). Возможно это связано с IBExpert ...

Игорь Столяров писал(а):Возможно это связано с IBExpert ...

Эксперт да, хорош! Потягаться с ним может, наверно, только Жаба. Странно, что не хотят поддерживать другие сервера (не FireBird). Может я не прав?

Игорь Столяров писал(а): и работает так, как должно работать (в отличии от MS SQL).

А в чём негатив от общения с MS SQL?

Shur писал(а): А в чём негатив от общения с MS SQL?

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

Игорь, какую версию IBExpert используешь?

У меня 2016.3.15.1 Personal Edition

IBExpert - кто знает как получить полную профессиональную версию -
есть ли варианты?

Есть в полной версии нужные опции. Согласен. Раньше была одна версия и для пользователей СНГ бесплатна (даже типа при старте определяет кодовую страницу Винды и всё). Сейчас что-то непонятное. Полную версию вообще нельзя скачать? Или она что-то требует?