Нахера ему для этого книгу читать?

Потому что она учит "определяться". Учит, что будет важно в одних случаях, что в других, и что вообще за случаи бывают.

Т.е. по-твоему, если человек пишет вопросик в чатик для определения, ему прям зайдет такой вариант как "иди сам определись, вот книга"?

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

Дай человеку рыбу, удочку и т.д.😁

То есть по твоему чайнику в чате нельзя говорить "иди определись", так? Вот нельзя и все? А как же тогда быть с https://t.me/Delphi_Lazarus/291092 ? #чотаржу Я хотя бы послал в конкретный текст, который учит определяться, а ты просто послал :)) д

Вот я и дал хорошую удочку

Где я послал? Я задал конкретный вопрос, на который он ответит и получит результат

"Определись, что тебе нужно от бд" Ага, чайник сразу все понял. И нет, даже для локальной кроме sqlite есть ещё Firebird embedded, если лезть вверх по функционалу SQL, а также есть куча разных nosql начиная с dbf и xml

Ты ему книгу дал "как ловить рыбу", а не удочку

Пусть так. Причём внутри описано какие удочки бывают и на что влияет выбор.

Ну да и прочтет там про старьё из 2000х

И это в данном случае хорошо. Не будет соблазна вместо понимания темы утыкаться в мелкие блёстки.

Это книга о делфи3! В книге не будет ни слова о современных БД для сравнения. Не будет обсуждения современных требований к БД и т.д. Ни даже актуальных способов работы с БД в Делфи

А такая книга есть, чтобы для полного новичка и чтобы все варианты? И чтобы именно обсуждения подходов, а не перепечатке рекламы последних версий Oracle или mssql? ...и если будет, оно будет про коммерческую delphi xe12, а не про Лазарь.

В продолжении темы. Предпологается однопользовательская приложение для работы на одном компе. Но есть нюанс. База должна быть разбитов на две части. В первой - справочники, каталоги. Во второй - текущий проект, где выполняются расчеты. Первая база в единственном числе, вторая может существовать в множественном числе, в зависимости от количества проектов. Как я уже понял, если и первая и вторая база находится на одном компе то подойдёт SQLite. Во втором случае, если первая база находится на сервере, и с ней работают несколько пользователей со своих компов, то лучше применение FB.

Когда у тебя справочники в одной базе а данные в другой - это лишает тебя возможности делать в запросах join данных со справочниками. Может быть неудобно, придется собирать все это на клиенте, вместо того что бы реализовать в запросе. Рассмотри вариант когда справочники импортируются в базу с данными. Это вызовет необходимость периодически импортировать данные, и увеличит занимаемое справочниками место в N раз, по количеству проектов, но зато появится возможность писать эффективные запросы (впрочем, неизвестно, нужно ли это в твоем случае) и работать с данными автономно при отсутствии связи с базой справочников.

Извиняюсь. Но ведь join к другой базе можно, я делала. MsSql

+1

FB не умеет. Про SQLite не знаю.

Обновите свои знания. Firebird умеет. А Sqlite можно научить при помощи TFDLocalSQL.

С какой версии?

https://www.firebirdsql.su/doku.php?id=execute_statement

EXECUTE STATEMENT нельзя вставить в секцию JOIN. Можно завернуть EXECUTE STATEMENT внутрь селективной процедуры и джойнить уже с ней. Ну и там же написано что: EXECUTE STATEMENT потенциально опасен: 1. Не делается никакой проверки запроса на выполнения. Так же не может быть проверен результат запроса и успешность его выполнения. 2. Не может быть выполнена проверка зависимостей в случае выполнения DML-оператора для гарантии того, что объекты, указанные в строке SQL операторов не удаляются из базы данных или не изменяются таким образом, который нарушит функционирование вашей задачи. Например, допускается выполнение команды DROP TABLE для таблицы, которая используется в откомпилированных процедурах или триггерах, что повлечет за собой сбой их работы. 3. В основном операции с EXECUTE STATEMENT более медленые так как не делается подготовка(prepared) запроса и, соответствено, подготовка происходит каждый раз при выполнении. Т.е. по сравнению с select - это медленнее, с кучей ограничений, с отсутствующей или усложненной диагностикой ошибок. Имхо, этот механизм - не для того что бы джойниться со справочниками.

это механизм для составления запроса внутри скрипта (или хранимки) и его выполнения

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

Справочники могут меняться пользователями? Или ты их формируешь при сборке программы один раз навсегда? Подумай над ещё одним вариантом. У тебя в программе внутри ресурсов (.rc или .DFM) ледит заготовка БД (в случае Firebird 2.5 embedded - упакованныц бэкап, .fbk.zip; в случае sqlite наверное есть что-то подобное тоже). Тебе ведь все равно при создании "нового документа" структуру БД создавать. Самый простой способ - тупо брать заготовку БД, которую ты сделал как часть программы, и разворачивать в новую БД. Но тогда в неё можно не только "таблицы да индексы" заложить но и те самые справочники. Пусть в каждом "документе" будет копия справочников. Для расчётов внутри SQL средствами SQL это проще, чем раздельные БД.

лень читать, базы на одном сервере?

Я не понял. Думаю что автор и сам этого не знает т.к. пока у него ничего нет. :)

Если же справочники делать отдельно, И не нужно чтобы пользователи их постоянно редактировали - я бы справочники оформил как .json.zip или .xml.zip и просто грузил в память при старте программы.

ну если на одном - то можно одним соединением и обойтись )

Ну в случае с FB

какая разница, MySQL тоже

что у FB входит в понятие "соединение с БД" ?

Ты утверждал, что firebird не умеет - умеет. Вопрос удобства использования не поднимался.

Если придираться к словам - то почитай на что я отвечал. Катерина: Но ведь join к другой базе можно, я делала. MsSql fraks: FB не умеет. Т.е.: 1. Речь была про join 2. В любом случае, так как это умееет делать MS SQL - FB не умеет. EXECUTE STATEMENT - это костыль, опасный, и не для этого.

MS SQL стандартом не является. Тем более не рекомендован к использованию на территории РФ

Кто-то утверждал другое?

Есть еще вариант обмениваться файлом сразу в формате SQLite и не заниматься парсингом. А может быть, если данные по проекту так же будут в формате SQLite то может быть энтот SQLite умеет делать джойны между разными базами. Он умеет весьма неожиданные вещи :)

Зачем обмениваться? Чем это лучше "спрятать готовую БД внутри exe" и какие сценарии разрешит?

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

Запросы у удаленным серверам практически одиннаково хреново работают во всех серверах. Оракл позволяет творить что угодно,в тч join, но и там косяк...удаленное соединение валидируется только в момент использования. Те отказ в самый неподходящий момент.