Когда мы проектируем реляционную базу данных, то должны во-первых руководствоваться правилами нормализации БД, о чем я уже писал в двух статьях немного выше. Нормализация БД - наш главный брат и помощник, а она ведет к разделению одной огромной таблицы 100x1 000 000 на несколько небольших, представляющих отдельные сущности: заказ, клиент, товар, поставщик и так далее. И встает вопрос: как-то же надо их связать воедино, чтобы они работали как один механизм, а транзакции выполняли все требования ACID, о котором я писал в предыдущем посте...

Самыми часто используемыми СУБД являются реляционные. Здесь данные представлены в виде сущностей и характеристик, и связей между этими сущностями. Базы данных ключ-значение — это представители широкого движения noSQL, здесь данные очень напоминает известные нам словари. Со словом ключом для поиска и соответствующей этому слову неструктурированная информация. Есть документоориентированные СУБД, которые реализуются так же на основе похода NoSQL, где в основе лежат хранилища, имеющие структуру, похожую на дерево...