Організація бази даних футбольних матчів, з урахуванням складів та ведення статистики щодо гравців
Прошу пробачення за сумбур, якщо потрібні уточнення з мого боку – з радістю їх надам.
mozyr: У знанні СУБД немає нічого сакрального. Півстоліття тому люди мучилися тими ж питаннями, що і ти зараз
Як зберігати Як отримувати швидко Як не гемороїтися з дублюванням Як перекласти турботи на автоматику та зайнятися справою
Щоб отримати все це довелося придумати реляційну алгебру, та якщо з неї отримати SQL і нормальні форми
3 (третя) нормалья форма - каже, що нам не потрібно зберігати купу повторів однієї і тієї ж сутності якщо ми маємо клуб - не потрібно його назву повторювати в кожній таблиці - достатньо послатися на його унікальний ідентифікатор ( id ) Аналогічно з футболістами, полями, чемпіонатами тощо
sql - дає можливість з купи таблиць зібрати дані в такій послідовності, як тобі потрібно
Тепер про термінологію noSQL != NOSQL без SQL != не тільки SQL Mongo != PostgreSQL
Навіщо взагалі можуть знадобитися БД без SQL, консистентності та інших плюшок?
Власне, є випадки, коли ти досяг такого розміру сховища, що ти не маєш можливості чекати синхронізації даних на нодах і ти сам можеш сказати, консистентні твої дані чи ні
Або коли тобі важлива консистентність блоку даних, які ніяк не пов'язані з іншими блоками.
mozyr: Впринципі, я б порадив тобі дописати проект на поточній бд або навіть впасти на рівень redis А потім переписати його з 0 на постгрес
Так у тебе буде порівняльнийдосвід на своїй шкурі, що дуже добре
Взагалі робити "неправильні" речі корисно для саморозвитку