Уважні читачі під минулим постом
Довелось гуглити. Кодд (той дядько, який придумав реляційну модель) у 1971 назвав чотири цілі нормалізації, і економії місця серед них нема. Там радше мова про зменшення кількості апдейтів під час операцій: менше дублів, менше операцій писання, кожна з яких займає час і може впасти. А от цілісність, якщо читати між рядків, серед цілей є.
Цілісність даних — це добре. Проте з ростом навантаження і скейлінгом цілісність починає бути проблемою. Власне, проблема не в цілісності. Проблема в механізмах для її забезпечення, зокрема foreign keys, які постійно перевіряють наявність записів під час вставки і гальмують систему.
Але насправді foreign keys потрібні лише за умови, коли з базою працюють люди вручну. Люди пишуть SQL команди вручну, десь помиляються, а база підстраховує.
Коли ж з базою працюють виключно застосунки, то вони і забезпечують цілісність. Дуже важко уявити собі ситуацію, коли у вас на продакшені стрельне foreign key violation, і це буде нормально. Насправді це означає, що у вас бага в коді або гонка між двома писунами (writers), що теж бага, і її треба фіксити. І виходить, що більшість перевірок працюють вхолосту в майже 100% і тупо уповільнюють систему. Саме тому серед порад "як пришвидшити роботу бази" трапляється "приберіть foreign keys". У GitHub їх не використовують взагалі, бо заважають шардити, у Shopify тільки на рівні коду.
Ще був комент, що для фінансових проєктів треба саме SQL, бо там транзакції. Але ж в реальному світі ACID майже ніде немає. Операція на кількох учасників майже ніколи не атомарна. Ти дістав гроші, віддав касиру, і раптом потухло світло чи вбіг грабіжник. Між моментом, коли ти віддав гроші, і моментом, коли вони з'явились на рахунку, проходить час. І в цей час може статися так, що і грошей у тебе вже нема, і на рахунку нічого не з'явилось. А потім це все треба якось вирішувати.
Банки з'явились задовго до комп'ютерів і якось працювали: папірці, пошта, процеси підтвердження, механізми компенсації. Гроші нікуди не зникали. Ті самі саги і компенсації, тільки на папері.
І десь під 2010, вся NoSQL двіжуха, а потім і мікросервіси, почала це впроваджувати: eventual consistency, сагі, компенсації. Виявляється, вони теж дають гарантії, яких достатньо для бізнес-процесів. Разом з тим NoSQL дозволяв простіше закривати проблемні місця реляційних баз: шардинг, міграції схеми на великій таблиці, масштабування запису, а не тільки читання.
Тепер про SQL як мову. Її придумано для людей, щоб їм було зручно працювати. І вона фантастична. Це один із перших декларативних підходів ( Prolog був ще раніше, якщо шо), коли ти кажеш, що тобі треба зробити, а як, вже вирішує база. Я не применшую її чеснот, і використовую її постійно. Мені простіше написати запит на SQL, аби поджойнити CSV файли, ніж згадувати аргументи методів pandas, наприклад.
А от коли з базою працюють програми, то все стає навпаки. Їм воно незручно. Передача параметрів, захист від SQL injection, query builders, ORM. Це все понапридумували в тому числі для того, аби інструмент під людей (SQL мова) підігнати під програми. Бо їм треба інші речі: структуровані API замість тексту.
Ну от, з коментарями розібрались (хоча завжди раді новим, наприклад — чому FK не можна просто взяти і прибрати). А в наступному пості перейдемо, власне, до баз, які мене вразили: це, звісно, Redis і DynamoDB.