LINUX.ORG.RU

Подскажите по схеме БД

 , ,


0

2

Всем привет!

В SQL новичек. Подскажите, как луче в MySQL организовать структуру для данных.

Есть таблица задач - tasks. Нужно сделать, чтобы задачи могли ссылаться друг на друга (связь многие-ко-многим). Можно сделать просто - создать доп.таблицу task_relations, где хранить id задачь:

CREATE TABLE IF NOT EXISTS `tasks` (
	   `id` INTEGER NOT NULL AUTO_INCREMENT,
	   `title` VARCHAR(250) NOT NULL,
           ...
   	   PRIMARY KEY (`id`)
) ENGINE='InnoDB';


CREATE TABLE IF NOT EXISTS `task_relations` (
	   `from_task_id` INTEGER NOT NULL,
           `to_task_id` INTEGER NOT NULL,
) ENGINE='InnoDB';

Но как организовать здесь внешний ключ - непонятно. Поможите чем можите, plz.


два ключа на каждое поле

bvn13 ★★★★★
()

Пока пришел вот к такому результату:

CREATE TABLE IF NOT EXISTS `task_relations` (
	   `id` INTEGER NOT NULL AUTO_INCREMENT,
	   `from_task_id` INTEGER NOT NULL,
	   `to_task_id` INTEGER NOT NULL,
	   PRIMARY KEY (`id`),
	   UNIQUE KEY `task_relations_from_task_id_to_task_id_uniq` (`from_task_id`,`to_task_id`),
	   CONSTRAINT `task_relations_from_task_id_fk_task_id` FOREIGN KEY (`from_task_id`) REFERENCES `tasks` (`id`),
	   CONSTRAINT `task_relations_to_task_id_fk_task_id` FOREIGN KEY (`to_task_id`) REFERENCES `tasks` (`id`)
) ENGINE='InnoDB' DEFAULT CHARSET=utf8 COMMENT='ololo';


Нормаc?

djnoob
() автор топика

Смотри, открываешь гугл, он находится по адресу https://www.google.ru, вводишь туда поисковый запрос, он очень сложный, смотри не ошибись: «mysql many to many example». Первая ссылка даст тебе ответ на твой вопрос.

Сложно было? Если ты не способен найти в гугле готовую инструкцию, скопировать SQL и выполнить в любом редакторе, то нахер из профессии.

hippi90 ★★★★★
()
Ответ на: комментарий от djnoob

Нормас, но я бы убрал поле id, и сделал бы primary key составным. У вас и так эта пара обозначена как альтернативный ключ (unique)

German_1984 ★★
()

Рисуй схему на бумажке, если совсем ничего не соображаешь и нет желания использовать спецсофт, вроде MySQL Workbench или Umbrella. Конечно, они не идеальны, но если нет понимания или схема громозкая чтобы держать её всю в голове/рисовать на бумаге, то они имеют место быть.

peregrine ★★★★★
()
Ответ на: комментарий от German_1984

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

theNamelessOne ★★★★★
()
Ответ на: комментарий от theNamelessOne

пользователь об этой таблице вообще не должен знать

bvn13 ★★★★★
()
Ответ на: комментарий от djnoob

вот что делает Hibernate (JPA) в Постгресе:

CREATE TABLE public.users_roles
(
  user_id bigint NOT NULL,
  role_id bigint NOT NULL,
  CONSTRAINT fk2o0jvgh89lemvvo17cbqvdxaa FOREIGN KEY (user_id)
      REFERENCES public.users (id) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION,
  CONSTRAINT fkj6m8fwv7oqv74fcehir1a9ffy FOREIGN KEY (role_id)
      REFERENCES public.roles (id) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION
)

bvn13 ★★★★★
()
Ответ на: комментарий от theNamelessOne

Пользователю вообще суррогаты вываливать не стоит.

Давайте проясню свою позицию. Я не утверждаю, что суррогатный ключ тут делать нельзя. Но основываясь на своем десятилетнем стаже разработчика БД я утверждаю, что в 99% случаев он тут не нужен, т.к. обращение всё равно будет идти по естественному составному ключу. В 90% случаев суррогат добавляется просто потому, что автор таблицы не знает что можно иначе. В 9% потому что «на всякий случай» и в 1% потому что ui фреймворк не умеет иначе.

German_1984 ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.