Comments 13
Справедливости ради, это не пример доступа к базам через пион. Это пример орм на фласке.
В наше время огромное количество данных формируется и хранится в базах данных, и умение эффективно работать с этой информацией — ключевой навык для аналитиков данных. В статье я расскажу о том, как использовать SQL для работы с данными в базах данных и как Python может стать мощным инструментом для доступа и анализа этих данных.
[...]
но так как мы изучаем Flask, а там обычно встроен SQLite, что делает его удобным для небольших и простых веб-приложений,
Так у вас статья про доступ к данным для анализа данных или про изучение Flask?
Это не статья, а какая-то каша. Взять немного фактов, причём не проверяя, правильно ли они взяты, добавить воды и перемешать. И.. надеюсь, всё же опечатки, а не ошибки, но что-то их многовато.
это называется Relation DataBase (связные таблицы).
Во-первых, таки Relational. Во-вторых, Database переводится как "база данных", при чём тут таблицы?
То есть, вместо того чтобы записывать одну большую таблицу, мы создали несколько. Данный процесс называют "нормализацией".
Данный процесс так не называется. Нормализация - это составная часть процесса разработки схемы, по которой будут создаваться эти "несколько таблиц".
Один к Одному (One-to-One)
В реальности практически не существует. Мало кто решается на создание такой связи. Обычно это One-to-(One or Zero).
Саморекурсия (Self-Referencing)
Всего лишь частный случай One-to-Many. Выделять его как какой-то особый тип связи - совершенно безосновательно.
======
Дальше, в общем, даже смотреть не стал. Как показывают предыдущие комментарии - наверное, и правильно.
Писали бы уж "мне лично one to one в практике не встречалось" . One to one (оно же горизонтальное партиционирование) типпичный прием при создании нагруженых систем, я буквально ежедневно вижу то на что "почти никто не решается" в реализации десятков разных систем...
По исходной статье - название действительно не соответствует содержанию
One to one (оно же горизонтальное партиционирование) типпичный прием при создании нагруженых систем, я буквально ежедневно вижу то на что "почти никто не решается" в реализации десятков разных систем...
Вы уверены, что имеете именно one-to-one? то есть оба взаимно-ссылающихся поля/выражения не только уникальны, но и NOT NULL? Такая связь реализуема далеко не в каждой СУБД, ибо требует отложенной проверки целостности внешних ключей. Если отложенной проверки нет, то при наличии такой связи ни в одну из ссылающихся таблиц нельзя добавить запись, ибо она не имеет соответствия в другой таблице, и проверка на ссылочную целостность в момент добавления приведёт к ошибке.
Я, например, использовал этот факт в MySQL для простого создания преопределённых статических Read-only таблиц - без удаления внешнего ключа с такой таблицей вообще ничего нельзя сделать... правда, ценой двойного дискового пространства.
Неплохая статья для начинающих, однако, автору следует попрактиковаться в написании статей и программировании. Рекомендую к прочтению чайникам.
Зачёт за картинку, правда очень понравилась. У меня тоже была идея объяснять, что такое (СУ)БД через сравнение с табличками Excel
Зачем?
Ну по сути, реляционные базы данных, иллюстрируются как эксель таблицы. Ну или эксель и реляционные базы внешне схожи, если не вдаваться в реализацию
статья хорошая, самое-то для начинающих :)
Введение в SQL & СУБД на примере доступа к данным через Python