Создание базы данных Firebird

[Tantos]

1. Правильно.
2. http://www.sql.ru/forum/624316/grant-option-2-chto-eto-znachit
3. Вопрос религиозно-философский . Мое мнение - если с этим полем идут операции связывания и выборки (JOIN и SELECT). Ну и про первичный ключ не забываем - индекс по нему создается автоматом.

[d7d1cd]

3. Вопрос религиозно-философский . Мое мнение - если с этим полем идут операции связывания и выборки (JOIN и SELECT). Ну и про первичный ключ не забываем - индекс по нему создается автоматом.

Только сегодня читал у Х. Борри про ключи 
Как я понимаю - это тот самый идентификатор записи (ID), который, как пишет госпожа Борри, очень даже рекомендуется создавать. Я создаю в моей таблице поле ID с автоинкрементом. Как сервер поймет, что для этого поля надо создать индекс? И почему этот индекс не отображается в списке индексов?

[Makin_tosh]

Можно работать и напрямую. Я использую процедуры для построения запросов - гораздо удобней внести изменения в процедуру, чем перекомпилировать код. Да и более менее сложный запрос проще реализовать через процедуру.

Разрешите вопросы:
1. Если в базе данных есть какие-то записи (у какого-то пользователя), то как тогда обновить эту процедуру? Раздача скриптов пользователям программы?
2. И, если потребуется пользовательский запрос, то тогда не обойтись без Query?

[Tantos]

Я создаю в моей таблице поле ID с автоинкрементом. Как сервер поймет, что для этого поля надо создать индекс? И почему этот индекс не отображается в списке индексов?

Как только ты сделаешь его первичным ключом, все будет - и индекс, и отображаться.
Makin_tosh,
1. Записи в базе не принадлежат какому-либо пользователю. У пользователя либо есть определенные права на определенные манипуляции с ним (вплоть до отдельных полей), либо нет.
Если база одна, то изменения вносятся в базу. Если у каждого пользователя своя база, то да, надо продумать режим обновления процедур. IBExpert умеет генерировать скрипты обновления, сравнивая эталонную и текущую базы.
2. Если пользователю потребуется новый запрос, то придется вносить изменения в программу. Хотя гуру умудряются хранить формы в базе...

[d7d1cd]

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

Как я понимаю, поле ID обязательно надо делать первичным ключом. Подскажите, как в IBExpert это осуществить.

[Tantos]

Поле необязательно должно называться ID .
На странице таблицы: вкладка "Ограничения"-"Первичный ключ", клавиша Insert.

[d7d1cd]

Поле необязательно должно называться ID .
На странице таблицы: вкладка "Ограничения"-"Первичный ключ", клавиша Insert.

Ну я понимаю, что не обязательно ID 
Объясните, пожалуйста, в чем смысл первичного ключа? Какие "сюрпризы" меня ждут если я не буду свое поле ID делать первичным ключом?

[Tantos]

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

[d7d1cd]

Как ты собираешься производить операции редактирования и удаления, не имея возможности однозначно определять записи в наборе?

Ну как то так: создам в таблице поле типа INTEGER, назову его ID, сделаю это поле с автоинкрементом, создав генератор и триггер BEFORE INSERT. Таким образом при добавлении каждой новой записи в таблицу, поле ID будет иметь уникальный номер. По нему я и буду однозначно идентифицировать запись для обновления и удаления. Заметьте, что при создании поля ID я не буду совершать эти действия: "вкладка "Ограничения"-"Первичный ключ", клавиша Insert".
Укажите, где у меня ошибка? 

[Tantos]

Ошибка? Я бы так это не назвал. Я бы сказал, что вами движет то ли Дух Противоречия, то ли  любопытство из серии "а давайте сделаем не так и посмотрим, что получится".
У вас какие-то свои представления о проектировании БД. Когда более опытный человек говорит вам как надо и как принято, вы, разумеется, можете делать по-своему - запретить вам никто не может. Но зачем вы тогда вообще спрашиваете?
Давайте договоримся так: я в последний раз отвечаю почему это должно быть ТАК, и больше мы к этому вопросу не возвращаемся?
Почему рекомендуется использовать автоинкрементируемое через триггер и генератор поле в качестве первичного ключа? Потому как это позволяет однозначно идентифицировать запись в таблице. Потому как генератор работает вне контекста транзакций, что гарантирует практические нулевую вероятность, что разным записям будет сгенерированно одно и то же значение, что приведет к конфликту в таблице.
Почему НУЖНО создавать первичный ключ? Потому как это позволяет и разработчику, и серверу БД ЗНАТЬ, на какое поле ориентироваться при идентификации записи. Потому как разработчики различных компонентов, облегчая работу конечному программисту, ориентируются именно на первичный ключ для автосоздания запросов. В конце концов, есть правила разработки и проектирования БД. И их игнорирование ни к чему хорошему не приводит.

[d7d1cd]

Наверное я не правильно выразился и поэтому Вы подумали, что у меня дух противоречия и прочее. Я не собираюсь делать все по-своему. Как раз наоборот: я хочу сделать все правильно, поэтому задаю вопросы. Вы отвечаете и говорите, что надо сделать именно вот так. Но ведь я должен понимать почему надо делать именно так, а не по-другому. Правда же? 

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

[Tantos]

d7d1cd, в целом - верно.
Видите ли, я не могу вам начитать курс проектирования и разработки БД на 2 страницах. Я не могу вложить в вас мой опыт разработки БД. Могу лишь дать советы по конкретным ситуациям и что-то подсказать.
Если вам интересно ПОЧЕМУ, читайте соответствующую литературу. Увы, не могу я вам в доступной форме объяснить, почему так нельзя. Ну вот не помню я теоретического обоснования, почему одно поле должно быть помечено как первичный ключ. А вот к чему это приводит на практике - помню.
Повторюсь, если вам нужна теория - это лучше не ко мне. Есть умные книжки, написанные умными людьми, где всё подробно расписано. Если у вас что-то конкретно не получается - спрашивайте. Я не гений, но кое-что подскажу. На этом форуме куча грамотных специалистов, которые гораздо опытней и умнее меня, так что нерешенной ваша проблема не останется.

[d7d1cd]

Я все понимаю. Будут вопросы - обращусь. Спасибо!

[d7d1cd]

Дошел до индексов. Объясните, пожалуйста, почему когда для столбца создан индекс, то поиск в нем будет быстрее? Например, в 2-х столбцах хранятся целые числа от 1 до 1000 вразброс. Первый столбец имеет индекс, второй нет. Сначала я делаю запрос всех строк, при условии, что в 1 столбце должны быть числа от 1 до 50. Потом делаю такой же запрос, при таком же условии, но для второго столбца. Почему в первом случае выборка будет быстрее? Ведь серверу и в первом и во втором случае надо просмотреть все значения в столбцах...  

P.S. Моя догадка: когда я делаю выборку по индексированному столбцу, то сервер ищет данные не в столбце, а по индексам. Так как индексы упорядочены, то он (сервер) будет "идти" по индексам до 50 и прекратит поиск.

P.S.S. Если догадка верна, то возникает другой вопрос: индексы - это абсолютно те же данные столбца, только отсортированные по возрастанию (или убыванию). И при добавлении (обновлении) строки, индексы вновь сортируются. Так?

[Tantos]

http://msdn.microsoft.com/ru-ru/library/s2aewe8z.aspx

[d7d1cd]

Спасибо за ссылку. Значит так: индекс рекомендуется создавать для столбцов, по которым будет происходить частый поиск информации. Индекс для первичного ключа создается автоматически. Но тогда получается, что если я создаю суррогатный первичный ключ и использую для него генератор и триггер, то:
1. Автоматически создаваемый индекс для этого столбца не нужен, так как поиск в столбце первичного суррогатного ключа производится не будет, ведь он суррогатный, то есть не несет "полезной" информации БД.
2. Значения в столбце и без индекса будут упорядочены по возрастанию, так как задаются генератором и не будут, по идее, меняться вообще.

В связи с этим вопрос: возможно ли отменить автоматическое создание индекса первичного суррогатного ключа? Или, так как стандарт Firebird ничего не знает о суррогатных ключах, нужно смириться с созданием этого индекса и, соответственно, с "ненужным" заполнением дискового пространства?

P.S. Если я опять чего то недопонимаю, то объясните, для чего может пригодится индексирование суррогатного ключа.
P.S.S. Нашел такую статью http://habrahabr.ru/post/107834/. Почитайте на досуге 

[Tantos]

Мнение Джоша Беркуса - это исключительно мнение Джоша Беркуса, не более того.
Не понимаю знака равенства между "суррогатный" и "не несет полезной информации". А какой несет? Суррогатный (он же искусственный) - означает, что мы добавляем это поле не на основе каких-либо данных из БД, а создаем дополнительно.
Я скажу четко и откровенно (да простят меня модераторы) - вы нереально зае...ли! Вы не имеете опыта в разработке БД, ни знаний в этой области. Какого черта я пытаюсь вам провести мини-ликбез, чтобы вы УЖЕ начали писать хоть ЧТО-ТО, а вы мне доказываете, что я все 10+ лет ошибался? Ну возьмите и свяжите через JOIN две таблицы по фамилии - посмотрим на результат и скорость выполнения запроса.
Ты б еще тут начал войну Windows vs. Linux.

В общем, так: когда у тебя будут КОНКРЕТНЫЕ вопросы с примером кода, который у тебя не компилируется - я вернусь в тему. До тех пор - арриведерчи.

[d7d1cd]

Спасибо за подталкивание к написанию уже чего то  Как только чего то наваяю, покажу.

[d7d1cd]

Привет всем. Решил не создавать новую тему и писать в этой же.
По настоянию Tantos'a решил уже что-то написать, да и в этом появилась реальная необходимость. Так как у меня новый компьютер, то я установил последнюю версию Firebird (2.5.3.26778 Win32), последнюю версию IBExpert 2014.9.29.1 и последнюю версию C++Builder XE7 (при установке были выбраны только Help Files и InterBase Express дабы не тратить дисковое пространство).
Далее я попытался создать в IBExpert пустую базу данных на основании имеющегося опыта. В диалоге создания я указал локальный сервер, имя базы, логин (SYSDBA), пароль (masterkey) и нажал ОК. Однако база не создалась, а я получил сообщение "unavailable database". Однако раньше создание базы подобным образом получалось. Я указал клиентскую библиотеку fbclient.dll из каталога с сервером Firebird, вместо библиотеки gds32.dll. Все удачно создалось.
Далее я создал пустой проект, положил на форму IBDatabase1, указал созданный файл базы данных, пароль, логин и попытался назначить свойству Connected значение true. Однако при этом я получил уже знакомую ошибку "unavailable database". В инспекторе объектов указано, что компонент IBDatabase1 использует библиотеку gds32.dll.

Подскажите, как в проекте указать, что необходимо использовать библиотеку fbclient.dll и почему раньше библиотека gds32.dll работала, а теперь нет?

[S0mbre]

Подскажите, как в проекте указать, что необходимо использовать библиотеку fbclient.dll и почему раньше библиотека gds32.dll работала, а теперь нет?

Если я правильно помню, FB создает 2 файла  с разными именами, которые по сути являются одной и той же библиотекой. gds32.dll создается для поддержки совместимости и (вроде как) копируется при установке в системную директорию... Подробности уточни в справке по FB.

[d7d1cd]

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

[d7d1cd]

Итак, свершилось!  Я наконец спроектировал кое-какую базу данных. Делал как можно проще. В базе 2 таблицы. Первая (CLIENTAGE) содержит 2 поля: ID и NAME. ID - суррогатный ключ, который сделан первичным. NAME - имя клиента. Вторая таблица (PROFIT) содержит 5 полей. Поле ID_CLIENTAGE - внешний ключ, определяющий клиента. PAYMENT_DATE - дата платежа, совершенного клиентом. TOTAL - общее количество прибыли, которое должно быть оплачено клиентом. DEBIT - оплаченная часть. KREDIT - задолженность.
Если кому-то не сложно, посмотрите, все ли я правильно сделал. Пароль и логин стандартные.