MySQL, связывающий две таблицы без третьей таблицы, содержащей отношения - PullRequest
1 голос
/ 18 февраля 2010

скажем, у вас есть две таблицы

table_a

f1 <- PKEY
f2
f3...

table_b

b1 <- PKEY
b2
b3...

теперь скажите, что table_a имеет отношение MANY к MANY с table_b

обычно у вас была бы третья таблица для хранения этих отношений

table_c

c1 <- PKEY
b1 <- PKEY of table_b
f1 <- PKEY of table_a

также скажите, что b1 + f1 по какой-либо причине не может быть PKEY table_c - просто ради аргументов.

Теперь было бы целесообразно / целесообразно сделать следующее

в table_a у вас есть поле MANY_Bs , в котором хранятся многие отношения, подобные этому:

table_a

f1:1

f2:'xyz data'

MANY_Bs: '1,2,3,4,5' 

(таким образом, показывая, что строка 1 в table_a связана со строками 1-5 таблицы_b)

затем используйте следующий запрос для выбора такого отношения

SELECT * FROM table_a, table_b WHERE
FIELD_IN_SET (table_b.b1, table_a.MANY_Bs)

Меня беспокоит: а) потеря преформальности б) потеря нормализации (мой мозг немного перегорел до тренировки (б) прямо сейчас)

Если какой-либо гуру MySQL видит какие-либо проблемы с такой настройкой?

Большое спасибо

Ответы [ 4 ]

2 голосов
/ 18 февраля 2010

Я думаю, что вы упустите пару вещей, используя предложенный вами метод. Например, если вы хотите удалить что-то в table_b, каскадирование должно быть выполнено вручную в table_a, менее читабельным (поскольку это нестандартно), и если вы хотите найти все строки в table_a с отношением к строке table_b, это будет медленно, так как у вас не может быть никаких индексов, и вам нужно будет пройти через все строки в table_a, чтобы убедиться, что вы нашли их все.

1 голос
/ 18 февраля 2010

теперь скажем, что у table_a были отношения один-ко-многим с table_b

обычно у вас была бы третья таблица для хранения этих отношений

Нет, вы бы не сталиобычно имеется третья таблица для отношения один ко многим.

См. документацию MySQL , в которой очень четко объясняется отношение один ко многим.

1 голос
/ 18 февраля 2010

Я не уверен, что понимаю вас правильно, но если вы хотите, чтобы отношение «один ко многим» от table_a к table_b вы могли просто добавить внешний ключ f1 из table_a в table_b.

0 голосов
/ 19 февраля 2010

Один-ко-многим вы применяете отношения с внешним ключом. Используя MySQL, используйте InnoDB для этого.

Многие-ко-многим вы справляетесь со столом посередине. Вот как это делается.

Теперь у вас есть выбор - у вас может быть проблема с переизобретением колеса (нет, не надо!) Или вы можете максимально использовать тот факт, что некоторые очень умные люди разработали теорию баз данных ( читать нормализацию для худых), а затем, и это очень важно, все другие умные люди, которые пошли дальше и создали реляционные базы данных (такие как MySQL, PostgreSQL, SQL Server, Access, Oracle и т. д.), основанные на всем, что они ' мы сделали на всей этой теории базы данных. Морщина здесь, вариации есть, но все это в значительной степени основано на одном и том же материале.

Итак, если вы собираетесь проектировать и создавать базы данных, потратьте некоторое время на изучение теории, лежащей в их основе, и разберитесь с ней в голове, так как тогда вы сможете работать с баз данных, а не несмотря на базы данных!

Это имеет смысл? Я не пытаюсь казаться странным, это был совет, который мне дали, и он сработал для меня!

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...