Есть довольно странный вопрос на который я вроде знаю ответ, но одновременно и нет.
Я не так относительно давно начал изучать основы баз данных. И многое для себя открыл, но накопились некоторые микровопросы, которые я не до конца понял.
1. Как понять какая база данных нужна для проекта реляционная или не реляционная ?
Да я вроде бы понимаю, что этот выбор нужно делать исходя из: структуры данных, гибкости схемы данных, масштабируемость, типов запросов/сложности запросов, скорости доступа к данным. Но может я не учитываю ещё какой-то фактор, ну и конечно я не совсем понимаю как исходя из этих факторов всё-таки сделать выбор ?(хотелось бы пример).
2.Какую конкретно базу выбрать ?
Тут примерно таже песня вроде бы надо основываться на: функциональности, масштабируемости, производительности, надежности. Но я видел и решения типа пиши на той с которой лучше знаком. И я взял ту, но как говориться немножечко не ту. Опять таки хотелось бы какой-то пример в духе в такой-то отрасли чаще используют такую базу (только давайте без дебатов на тему эта база быстрее той на столько-то в такой узкой задаче, я надеюсь вы понимаете о чём я).
Иерокопус Таманский, я прежде чем задавать вопросы смотрел нет ли похожего, и видел все эи вопросы. Но как мне кажется они очень узко заданы, в духе: "У меня должно быть много клиентских подключений к базе, и скорость запросов такая, скорость операций такая". Я не думаю, что это плохие вопросы просто хочу выяснить для себя как правильно. Чтобы по возможности, в дальнейшем не дополнять эту ветку https://qna.habr.com/search?q=выбрать+базу+данных своими вопросами.
Если не знаешь, почему тебе нужна нереляционная - бери реляционную, тк наиболее гибкое и какие-то возможные проблемы будет легче всего обойти.
Какую конкретно? Ту, которую лучше знаешь, если не можешь назвать конкретную причину, почему лучше изучить другую и взять другую. Например вот я беру postgres по-умолчанию, но вот у меня проект, который требует минимального жора ресурсов и наиболее простой инфраструктуры - тогда беру sqlite.
Или наоборот - я понимаю, что у меня какие-то специфичные требования по консистентности и доступности, система у меня будет распределённая, а запросы у меня будут исключительно key-value, да и желательно ещё иметь возможность подписки на изменения каких-то ключей - тогда беру etcd.
1. Если в разрабатываемой системе нет потребности производить нечеткий поиск, получать сверхбыстрый ответ на запрос в реальном времени (не более пары миллисекунд), производить аналитику данных в самых разных разрезах. У вас в потоках данных определены сущности с четкими реквизитами и сущности имеют высокую связность, то в 99% случаях вы даже не повернете голову в сторону нереляционных СУБД, будете использовать реляционные.
2. На самом деле, просто зависит от того, как сложно администрировать СУБД в том масштабе, в которой развилась база данных. Сначала берут первую попавшуюся, или с тем, с чем освоились более-менее, а потом смотрят с течением времени, как сложно нанять нужного специалиста на администрирование, удобно ли масштабировать экземпляры баз данных при возросшей нагрузке, удобно подымать экземпляры из небытия, держать непрерывный аптайм. Вот тут уже выясняется специфика работы предметной области и необходимость переезжать на подходящее окружение.
alexalexes, очень хороший ответ спасибо. Собственно из-за чего возник такой вопрос у меня, просто при обсуждении нового проекта, начальник сказал что в нём(в проекте) точно используй реляционную базу. И у меня закралась тень сомнения, о том как он пришёл к такому выводу(т.к. моих знаний пока не достаточно). Тем более он сказал, что задача которая перед нами стоит чисто реляционная и тут я такой ага. А сам не допонял как это.
Простой
Простой
