Отношение многие к одному в mysql

FRE5H
Member
Откуда: Украина
Сообщений: 6
Вопрос такой? Есть ли синтаксис в MySQL для создания связи одни-к-одному?
Именно такой связи!
Почему возник такой вопрос, потому что случайно обнаружил, что для создания связи один-к-одному и один-к-многим - синтаксис одинаковый. Т.е. это синтаксис создает всегда связь один-ко-многим!!! Типа ты думаешь, что создаешь связь один-к-одному, а на самом деле получается связь один-к-многим
Пожалуйства подтвердите либо опровергните это... А то облазил весь инет, вроде как убежден в своих словах, но хочу быть уверенным :)

P.S. Есть один способ, как создать искуственно эту связь: сделать связь один-к-многим, той колонке, к которой подключается "много" поставить уникальный индекс. Но почему-то думал, что MySQL это позволяет сделать одним синтаксисом :(

Warstone
Member
Откуда:
Сообщений: 4896
Блог
Теория баз данных говорит о том, что в БД не должно быть связей отношение многие к одному в mysql 1 к 1. Если у вас такая есть - надо переделывать БД.

Фактически, такие связи нужны очень редко и в этом случае можно сделать и 1-ко-многим с уникальным индексом.

Кстати, такой вещи как 1-к-1 нету и в Пг, насчет Оракла и МС - не скажу, но, скорее всего, - тоже нету.

Akina
Member
Откуда: Зеленоград, Москва, Россия
Сообщений: 15828
Warstone
Теория баз данных говорит о том, что в БД не должно быть связей 1 к 1. Если у вас такая есть - надо переделывать БД.
Именно практика требует наличия возможности разделения таблицы на части, связанные 1:1. Ради экономии ресурсов. FRE5H
Есть один способ, как создать искуственно эту связь: сделать связь один-к-многим, той колонке, к которой подключается "много" поставить уникальный индекс.

Чисто теоретически - связь 1:1 имеет смысл лишь в случае, когда эта связь организуется по первичным индексам таблиц. При этом требование уникальности имеется по дефолту.
А вот если связь 1:1 потребовалась по другим полям - полностью соглашусь с предыдущим оратором по поводу кривизны структуры.
RXL
Member
Откуда:
Сообщений: 1600
CREATE TABLE a ( id INT PRIMARY KEY ); CREATE TABLE b ( id INT PRIMARY KEY );

Получается 1:[0|1].

tanglir
Member
Откуда:
Сообщений: 30154
RXL,

а триггеры на что?

Warstone
Member
Откуда:
Сообщений: 4896
Блог
Akina
Warstone
Теория баз данных говорит о том, что в БД не должно быть связей 1 к 1. Если у вас такая есть - надо переделывать БД.
Именно практика требует наличия возможности разделения таблицы на части, связанные 1:1. Ради экономии ресурсов.
Для этой фразы был написан 2-й абзац.

Все 3 абзаца вели к мысле, что 1-к-1 настолько редки, что выделять его в отдельный случай (кстати, идея с PRIMARY KEY в обоих таблицах - рассово верна и должна использоваться. PK все-равно надо делать, а так нету лишней проверки) не надо.

Akina
Member
Откуда: Зеленоград, Москва, Россия
Сообщений: 15828
Warstone
Все 3 абзаца вели к мысле, что 1-к-1 настолько редки

Если анализировать реальные большие базы - во многих найдутся таблицы на миллионы и более записей со значительным количеством полей. А если анализировать эти таблицы - опять-таки во многих случаях реально работает лишь небольшое количество этих полей, а остальные тащатся "обозом", надобятся редко и только на выдаче конечной выборки, а памяти и дискового пространства жрут мама не горюй. И вырезание этого ломтя в отдельную таблицу нередко очень положительно сказывается на самочувствии сервера - особенно если он не имеет десятикратного запаса прочности по всем параметрам...
Другой вопрос, что это не всегда верно анализируется на стадии начального проектирования, а на конечном продукте такое разделение "на лету" способно, наоборот, резко ухудшить самочувствие пациента - и ситуацию оставляют в том виде, в каком она есть. Проще добавить оперативки, чем перелопатить базу и приложения на ней.
RXL
Member
Откуда:
Сообщений: 1600
Я поддерживаю биллинговую систему. Около семисот таблиц, более двух тысяч индексов, тридцать гиг диска (правда некоторые тут скажут, что это мало, но сейчас это не суть важно). Используется не MySQL, но принципы реляционных баз для всех едины. В общем, принцип "один к одному" там сплошь и рядом. Стержневыми таблицами являются списки событий, транзакций и т.п. данные, которые не могут иметь истории, т.к. сами являются фактами во времени. К этим таблицам подтягиваются множество таблиц с другими данными со своими же собственными историями, синхронизированные по id со стержневой. Громоздко, но разумно. Не представляю, сколько бы весила та же таблица транзакций, если бы в ней были все поля подчиненных таблиц.
Warstone
Member
Откуда:
Сообщений: 4896
Блог
RXL
Я поддерживаю биллинговую систему. Около семисот таблиц, более двух тысяч индексов, тридцать гиг диска (правда некоторые тут скажут, что это мало, но сейчас это не суть важно). Используется не MySQL, но принципы реляционных баз для всех едины. В общем, принцип "один к одному" там сплошь и рядом. Стержневыми таблицами являются списки событий, транзакций и т.п. данные, которые не могут иметь истории, т.к. сами являются фактами во времени. К этим таблицам подтягиваются множество таблиц с другими данными со своими же собственными историями, синхронизированные по id со стержневой. Громоздко, но разумно. Не представляю, сколько бы весила та же таблица транзакций, если бы в ней были все поля подчиненных таблиц.
Сам занимаюсь примерно тем-же... (Объемы примерно те-же, правда достигаются за счет партицирования, а так это mediation система) И, позвольте угадать, Пг? А нет... Oracle, да?..

Вообще, конечно, интересно на схему посмотреть... Возможно вы правы, возможно нет ))

Я не против связи 1-к-1, более того, из-за модульности 1-к-1 может быть оправдан (в купе с дублированием некоторого количества данных), но что-бы выделять отдельную конструкцию?

FRE5H
Member
Откуда: Украина
Сообщений: 6
Спасибо за ответы. 1-1 конечно нужно, очень часто встречаются такие случаи. Теперь я убедился, что в MySQL такого синтаксиса нету, нужно самому выкручиваться. К примеру так
Таблица 1 (ИД - автоинкремент, Поле 1, Поле 2)
Таблица 2 (ИД - без автоинремента, Поле 3, Поле 4)
И ставлю такое условие: Таблица1.ИД один-к-многим Таблица2.ИД, Таблица2.ИД - уникальный индекс
RXL
Member
Откуда:
Сообщений: 1600
Warstone,

Да, Оракл. Система разработана в Штатах еще в 90-х, а в таких условиях любая другая СУБД была маловероятно.

RXL
Member
Откуда:
Сообщений: 1600
Warstone,

Кстати, без партицирования: изобилие индексов данную процедуру полностью лишает смысла. БД спроектирована без использования PK, но все остальные индексы UNIQUE.

Виртуальные форумы   Темы из всех форумов за 3 дня   Мои избранные форумы Использование СУБД   Microsoft SQL Server   Firebird, InterBase   Oracle   Microsoft Access   IBM DB2, WebSphere, IMS, U2, etc   MySQL   PostgreSQL   OLAP и DWH   Sybase ASA, ASE, IQ   Informix   Другие СУБД   FoxPro, Visual FoxPro   Caché   SQLite   NoSQL, Big Data Дискуcсии   Сравнение СУБД   Проектирование БД   Работа   ERP и учетные системы   Разработка информационных систем   Тестирование и QA   Отчетные системы   Просто треп   Наши за рубежом   Сертификация и обучение   Hardware   Управление процессом разработки ИС   Юридические вопросы в ИТ Microsoft.NET   WinForms,.Net Framework   ASP.NET одному   ADO.NET, LINQ, Entity Framework, NHibernate, DAL, ORM   WPF, Silverlight   WCF, Web Services, Remoting Программирование   Delphi   C++   Visual Basic   Программирование   Java   Разработка под мобильные платформы   PowerBuilder   Microsoft Office   SharePoint   XML, XSL, XPath, XQuery Web Технологии   PHP, Perl, Python   HTML, JavaScript, VBScript, CSS Администрирование ОС   Windows   Unix-системы   Другие: Mac OS, PalmOS, BeOS, PocketPC SQL.RU   Обсуждение нашего сайта   Вопрос-Ответ   Test



Рекомендуем посмотреть ещё:


Закрыть ... [X]

Отношение «многие -ко-многим» / 12. Использование нескольких таблиц / MySQL Красивые картинки на стены своими руками

Отношение многие к одному в mysql Отношение многие к одному в mysql Отношение многие к одному в mysql Отношение многие к одному в mysql Отношение многие к одному в mysql Отношение многие к одному в mysql