Организация базы данных футбольных матчей, с учетом составов и ведением статистики по игрокам. Правильно ли делать на JSON + noSQL?
Хочу сделать базу данных футболистов и футбольных матчей моего локального футбольного клуба. Т.е. собрать статистику по примерно 20 сезонам. Даты, счет, составы, авторы голов - вот это вот все. Примерно 20 футбольных сезонов и около 700 матчей. Все это есть в бумажном виде (спортивные газеты, записи) и хотелось бы структурировать в электронном виде. Выбор пал на RethinkDB, как на самую понятную noSQL бд и JSON как способ обращения к ней + node,js для автоматизации всего этого добра. Все это городится с помощью собственных костылей - через боль и тостер. Возможно есть более универсальный способ построения такого рода базы данных или есть какие-то другие инструменты для решения задачи ?
База данных, в общем-то подойдет и размещенная локально, но, разумеется, размещение в интернете лишним не будет.
Прошу прощенья за сумбур, если нужны уточнения с моей стороны - с радостью их предоставлю.
Если ты готов сам отвечать за консистентность данных, вручную считать всю статистику, следить за исправлениями во всех местах, готов писать сотни велосипедов на простейшие задачи и делать другие не очень интересные вещи, то твой выбор noSQL
Безусловно, мне хотелось бы получить максимальный результат, прикладывая минимальные усилия. Если вы подскажите мне более простое решение задачи - буду очень вам благодарен, потому что мои познания в базах данных крайне малы.
mozyr:
в знании СУБД нет ничего сакрального. Полвека назад люди мучались теми же вопросами ,что и ты сейчас
Как хранить
Как получать быстро
Как не гемороиться с дублированием
Как переложить заботы на автоматику и заняться делом
Чтоб получить все ето пришлось выдумать реляционную алгебру, а из нее получить SQL и нормальные формы
3 (третья) нормалья форма - говорит, что нам не нужно хранить кучу повторов одной и той же сущности
если у нас есть клуб - не нужно его название повторять в каждой таблице - достаточно сослаться на его уникальный идентификатор ( id )
Аналогично с футболистами, полями, чемпионатами и тд
sql - дает возможность из кучи таблиц собрать данные в такой последовательности как тебе нужно
Теперь про терминологию
noSQL != NOSQL
без SQL != не только SQL
Mongo != PostgreSQL
Зачем вообще могут понадобиться БД без SQL, консистентности и др плюшек?
Собственно, есть случаи, когда ты достиг такого размера хранилища, что у тебя нет возможности ждать синхронизации данных на нодах и ты сам можешь сказать, консистентны твои данные или нет
Или когда тебе важна консистентность блока данных, которые никак не связаны с другими блоками
Аналогия - если у тебя есть задача осветить внутренние чемпионаты Андорры и Монголии - монга тебе прекрасно подойдет
девушка есть, даже жена уже. и дети есть. и убунту есть на малине установленная, а вот знаний достаточных для грамотного решения поставленной самому себе задачи нет. поэтому и вопрошаю ) какое решение вы считаете более удачным ?
mozyr: ну, про девушку не вам было;)
я бы mysql использовал, либо любое другое реляционное хранилище, очень уж ваша схема данных в него укладывается.
но, если у вас сроков нет, то можете и ту штуку попробовать, окажется ее достаточно - и хорошо, будет недостаточно - конвертируете в mysql...
тут самая большая сложность - именно в оцифровке данных
