Python-сообщество

py.user.next
Реляционная база данных - это база данных, состоящая из отношений.

Можно было ещё упомянуть что отношения бывают четырёх видов. Отношение “один к одному” можно представить как просто запись в таблице. Отношения “один ко многим” или “многие к одному” требуют, как минимум, двух таблиц, связанных внешними ключами. Отношение “многие ко многим” приходится приводить к предыдущим двум видам с помощью дополнительной стыковочной таблицы.

py.user.next
Так как множество - не упорядоченная структура, то в нём нет первого кортежа или последнего кортежа.

Не представляю, как можно работать с беспорядочными данными. Надо наводить порядок! Например, с помощью первичного ключа. Как правило, первичный ключ отражает хронологию добавления записей. Или можно упорядочить данные с помощью запроса ORDER BY column. У нас есть возможность самим определить какую запись считать первой, а какую - последней.

py.user.next
Это не таблица со строками, это множество с кортежами. Там не может быть секций

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

> Можно было ещё упомянуть что отношения бывают четырёх видов

Это не отношения, а связи.

> Не представляю, как можно работать с беспорядочными данными

py.user.next любит выёживаться, но сам плохо знает теорию. Например его цитата про множества говорит о том что он не понимает различий между реляционной алгеброй и SQL-ом.
Вот почитай учебник по основам теории, там всё хорошо написано: https://postgrespro.ru/education/books/dbtech

> И Вы, и Rodegast, единогласно предложили мне использовать для логического разбиения таблицы на “секции” составной ключ

Я такого не предлагал. Никакие таблицы на секции ре разбиваются, для решения твоей задачи нужно использовать составной индекс. Ключом он не является.

Rodegast
Это не отношения, а связи.

Rodegast
составной индекс. Ключом он не является.

Прошу прощения, запутался в нюансах.
Давно поглядываю в сторону Постгреса. Но, для начала, тренируюсь на “кошках” попроще. Со временем и теорию подтяну и до Постгреса доберусь. Надеюсь.

Alex.Pro.
Можно было ещё упомянуть что отношения бывают четырёх видов. Отношение “один к одному” можно представить как просто запись в таблице. Отношения “один ко многим” или “многие к одному” требуют, как минимум, двух таблиц, связанных внешними ключами. Отношение “многие ко многим” приходится приводить к предыдущим двум видам с помощью дополнительной стыковочной таблицы.

Вот об этом я тебе и говорю, что ты не знаешь значения слова “реляционная”.

Rodegast
py.user.next любит выёживаться, но сам плохо знает теорию. Например его цитата про множества говорит о том что он не понимает различий между реляционной алгеброй и SQL-ом.

wiki. отношение

Да, отношение - это множество такое. Если энка (кортеж из n элементов) входит в это множество, то эта энка принадлежит отношению. А если этой энки там нет, то она не принадлежит отношению. Если энка принадлежит отношению, то её элементы находятся в этом отношении друг с другом. А если энки там нет, то её элементы не находятся в этом отношении друг с другом.

Так что SQL'а там или какой-то СУБД типа PostgreSQL или SQLite там и рядом нет. Ещё до языка запросов определяются все эти понятия. Это потом там вводится язык запросов, и один из этих языков, которые там могут быть, - это язык SQL.

Rodegast
Вот почитай учебник по основам теории

Вот там полезная фраза

Реляционная модель появилась в начале 1970-х гг. в работах
Э. Кодда (Edgar Codd) и ряда других исследователей. Большую роль в популяри-
зации идей реляционной модели данных сыграли работы К. Дейта (Christopher
Date).

Вот их работы надо читать. Но для этого надо знать английский, иначе придётся читать перепечатывальщиков, которые вот чужую теорию где-то собирают и потом в своих книжках за свою выдают, якобы это их труды, и для этого маскируя это всё за пересказами кусков этой теории своими словами. И переводы тоже бывают не очень качественными, поэтому на английском может быть написано всё ясно, просто и понятно, а перевод того же самого может быть якобы правдивым и правильно переведённым даже, но при этом о-о-о-очень запутанным. Я таких переводов много встречал, начиная от описания Scrum'а, заканчивая объектно-ориентированными теориями, где просто по-русски написана какая-то сложная и несогласующаяся обтекаемая ерунда, а по-английски всё просто и понятно и однозначно.

Rodegast
py.user.next любит выёживаться

Так у тебя с английским проблема, это твой барьер, который тебя держит с шорами на глазах. А у меня этого барьера нет, я могу побежать налево, могу побежать направо. Когда ты читаешь одну книжку, переведённую три года назад (и это свежак), я в это время читаю три книжки, которые и переведены, и не переведены. Поэтому я узнаю с разных сторон одно и то же, я как бы смотрю на слона с позиций всех трёх слепцов, стоящих с разных сторон от него.

Alex.Pro.
Как правило, первичный ключ отражает хронологию добавления записей.

Не, ничего подобного. Это у тебя тоже заблуждение. Ты думаешь, что первичный ключ - это id в числовом виде, но первичный ключ иногда может быть id в числовом виде, а может быть и Таня-Наташа в контексте того, кто там водку покупал, а кто коньяк. И там может не быть поля id вообще, оно вообще может ещё и мешать к тому же.

У тебя ошибка стандартная. Ты думаешь, что если ты прочитал инструкцию к СУБД, то ты понял всё про базы данных и осталось узнать лишь какие-то мелочи там немногочисленные.

Надо, наоборот, начинать изучение с теории организации данных и постепенно приходить к СУБД. А если начинаешь с СУБД и движешься к теории, то тогда и называешь отношения таблицами, или там считаешь, что реляционное - это всё про SQL и так далее. В итоге у тебя куча неверных знаний. А из них ничего не соберёшь, потому что из неправильных знаний можно собрать только неправильную базу данных.

Отредактировано py.user.next (Дек. 19, 2024 07:12:05)

> Давно поглядываю в сторону Постгреса. Но, для начала, тренируюсь на “кошках” попроще

Книжка не про postgresql, а про теорию. Во всяком случае первую часть стоит прочесть + посмотри видео.

> wiki. отношение .. Так что SQL'а там или какой-то СУБД … Так у тебя с английским проблема, это твой барье

Ой как чебурашку бомбанула! Ещё раз для тебя повторяю. SQL и реляционная алгебра описывают разные модели данных с разной терминологией. Ну а твоё выё… меня просто веселит, а вот Alex из за него запутывается. По этому лучше молчи в тряпочку, за то за умного не сойдешь

Alex.Pro.
Пока у нас в таблице дома с одной улицы - их номера уникальны. А если у нас больше одной улицы - номера домов на разных улицах могут повторятся.

Поправьте если неправильно рассуждаю.
У одного номера может быть много разных улиц.
У одной улицы может быть много разных номеров
первая таблица будет Улицы: id | название улицы
вторая таблица Номера: id | номер
во второй таблице номер сам по себе уникален поэтому для него нет смысла делать таблицу.

эти данные связаны например в таблице Адреса: id | id_улицы | номер_дома
если эти данные нужно привязать например с неким зданием,то будет таблица
Здания: id | id_названия(школа, больница, и тд..) | id_адреса
видим что у одного здания может быть один адрес, тогда таблицу Адреса можно сооединить с этой таблицей Здания,
id | id_названия | id_улицы | номер_дома

xam1816
У одного номера может быть много разных улиц.
У одной улицы может быть много разных номеров

Ну… Примерно так у меня и получается. Так, да не так. Таблица “Номера” сразу оказывается лишней. Из-за того, что мне надо отображать данные целого списка домов, номер дома мне удобнее хранить не в стыковочной таблице “Адреса”, а в таблице “Дома”. В таблице “Дома” собраны данные домов с разных улиц, поэтому номер дома сам по себе теряет уникальность. Уникальность обеспечивается комбинацией адреса с номером дома.
Грубо говоря, у меня получается такая структура БД:
table Region: Primary_id | Region_name | Properties
table City: Primary_id | City_name | Properties
table Street: Primary_id | Street_name | Properties
table Address: Primary_id | Foreing Region_id | Foreing City_id | Foreing Street_id
table Building: Primary_id | Unique (Foreing Address_id | House_No) | Property.1 | Property.2 | Property.N

Alex.Pro.
Уникальность обеспечивается комбинацией адреса с номером дома.

Уникальность дома обеспечивается его Id в таблице, почему нужно определять его уникальность улицей и номером дома? В разных городах может быть дом с адресом Ленина 20 например. Тогда нужно связку: город, улица ,дом. Так и города есть одинаковыми названиями. В чем уникальность тогда?

> У одного номера может быть много разных улиц.

Нет, один и тот же дом располагаться сразу на нескольких улицах не может.

> Ну… Примерно так у меня и получается. Так, да не так.

Сделай ER-модель, иначе будешь путаться. И желательно её делать сразу в моделере, я обычно PgModeler использую, но для Sqlite он не подойдёт.

Отредактировано Rodegast (Дек. 20, 2024 14:04:57)

xam1816
Уникальность дома обеспечивается его Id в таблице, почему нужно определять его уникальность улицей и номером дома?

Если уникальность номера дома определять только его id в таблице, то появляется возможность несколько раз добавить в таблицу один номер дома, но с разными id. Мне не нужно такое дублирование.
Использовать номер дома в качестве id тоже нельзя, потому что придётся плодить таблицы с номерами домов по одной на каждую улицу.

xam1816
В разных городах может быть дом с адресом Ленина 20 например. Тогда нужно связку: город, улица ,дом.

Всё правильно. Выше я приводил упрощённую структуру моей БД. Есть таблица Address, в которой, в качестве адреса, собраны записи с идентификаторами региона (области, края), города и улицы. А в таблице Building номер здания связан с id записи из таблицы Address. И уникальность номера дома обеспечивается именно этой связкой. Хотя в столбце House_No могут быть повторяющиеся номера, но в связке с адресом они становятся уникальными.
By the way: я тренируюсь на адресе Ленина 24. Угада! Экстрасенс?

Rodegast
Сделай ER-модель, иначе будешь путаться.

Не помогло. Или помогло, но слабо. Сначала обдумывал в голове, потом пытался моделировать в MySQL Workbench. Потом начал писать код и модель стала меняться по ходу. Трудно было начать. На сегодняшний день более-менее разобрался, процесс идёт нормально.

Отредактировано Alex.Pro. (Дек. 20, 2024 16:05:56)