py.user.nextМожно было ещё упомянуть что отношения бывают четырёх видов. Отношение “один к одному” можно представить как просто запись в таблице. Отношения “один ко многим” или “многие к одному” требуют, как минимум, двух таблиц, связанных внешними ключами. Отношение “многие ко многим” приходится приводить к предыдущим двум видам с помощью дополнительной стыковочной таблицы.
Реляционная база данных - это база данных, состоящая из отношений.
py.user.nextНе представляю, как можно работать с беспорядочными данными. Надо наводить порядок! Например, с помощью первичного ключа. Как правило, первичный ключ отражает хронологию добавления записей. Или можно упорядочить данные с помощью запроса ORDER BY column. У нас есть возможность самим определить какую запись считать первой, а какую - последней.
Так как множество - не упорядоченная структура, то в нём нет первого кортежа или последнего кортежа.
py.user.nextТаблица со строками - это удобное визуальное представление данных в БД. Видимо, поэтому слова table, column, row повсеместно используются для описания структуры БД и синтаксиса SQL. Хотя бы для облегчения понимания.
Это не таблица со строками, это множество с кортежами. Там не может быть секций
Когда я говорил о “секциях” таблицы, во-первых, я взял это слово в кавычки. Во-вторых, я привёл пример, каким образом таблица в моей БД должна логически разбиваться на “секции”. И Вы, и Rodegast, единогласно предложили мне использовать для логического разбиения таблицы на “секции” составной ключ. Понятно, что при этом порядок хранимых в БД данных не меняется, но появляется возможность получать и отображать данные из БД “посекционно”.
Да, ещё существует запрос GROUP BY columns, который тоже позволяет получать данные из БД “посекционно”.
Короче, не важно как организованы данные внутри БД и в каком порядке хранятся записи. При желании, мы можем получить и отобразить данные в нужном порядке, в удобном (табличном) виде и в требуемом об'ёме.
