Тут я понимаю так, что всё же у рецепта есть множество вкусов, соотв.

Ну, было бы логично. В общем , FOREIGN on delete cascade работает с родительской стороны. Если есть папа, и у него есть дети, и есть FOREIGN on delete cascade , то когда папа всё, его дети тоже исчезают.

Хотя что-то я вроде нагнал...

сплю.

DELETE FROM flavor WHERE recipeid = 1;

не удаляет recipe

DELETE FROM recipe WHERE ID = 1; так не удаляет flavor

тебе что вообще надо удалять в зависимости от чего

recipe.flavorid имеет несколько flavor.recipeid. Мне нужно при удалении recipe удалялись все flavor.recipeid, связанные с ним

А у меня получается, то одно удаляется другое остается, то наоборот

нет никакого recipe.flavorid

а foreign key должен ссылаться на recipe.id

CREATE TABLE flavor ( name TEXT, drops INTEGER, recipeid INTEGER REFERENCES recipe (id) ON DELETE CASCADE ON UPDATE CASCADE );

нет никакого recipe.flavorid

flavorid INTEGER есть

Разве не надо указать FOREIGN KEY для receipid?

flavorid INTEGER есть

и что ты туда положишь?

Разве не надо указать FOREIGN KEY для receipid?

Так он указан recipeid ссылается на id

и что ты туда положишь?

генерю случайно число, где recipeid = flavorid

зачем тебе колонка со случайным числом и на что влияет это равенство?

Случайно число, чтобы избежать совпадений, т.е чтобы к рецепту не относились вкусы, не относящиеся к нему на самом деле

Равенство привязка вкусов к рецепту

Вы уже поняли.Но объясню еще раз, вдруг что упутил

Есть 2 таблицы. Вкус и Рецепт. Рецепт имеет связь один ко многим.Т.е рецепт может иметь один вкус или несколько.

И что удалять ?

При удалении рецепта должны удаляться вкусы связанные с ним

Есть 2 таблицы. Вкус и Рецепт. Рецепт имеет связь один ко многим.Т.е рецепт может иметь один вкус или несколько.

Да, и каким образом здесь возникнет несуществующая связь вкусов и рецептов?

А если вкус связан с НЕСКОЛЬКИМИ рецептами ? А один из них мы удаляем ?

у каждого вкуса только один родительский рецепт, по этой связи все и выбирается

А если вкус связан с НЕСКОЛЬКИМИ рецептами ? А один из них мы удаляем ?

Вкусы могут быть одинаковые но они относятся в разным рецептам.

Сейчас поясню

Вкусы могут быть одинаковые но они относятся в разным рецептам.

Это странно.

Тогда у вкуса должен быть составной PK, из рецепта и номера вкуса внутри рецепта.

ТОгда да.

У тебя кстати PK вообще нет...

Тогда у вкуса должен быть составной PK, из рецепта и номера вкуса внутри рецепта.

зачем

ТАК НАДО,...

во flavorid нету, но все на вывод работает, на удаление нет. SELECT * FROM recipe LEFT JOIN flavor ON recipe.flavorid = flavor.recipeid WHERE id = ?" вывожу так

Не обязательно конечно, но логично было бы.

Ладно, я похоже что-то пропусти.

может так понятно, будет

могу ссылку на гитхаб дать.

Короче, всё правильно у тебя было изначально. Только мы тормоза.

(я в частности)

Короче, всё правильно у тебя было изначально. Только мы тормоза.

Это конечно радует, но как удалить

ссылаться на recipe.id

Делаю на go. Хотел двумя DELETE FROM * WHERE recipeid = * и также для второй таблице

Но мне сказали каскад работает, но не у меня

Блю......

PRAGMA foreign_keys = ON; CREATE TABLE flavor ( id INTEGER PRIMARY KEY, name TEXT, recipe_id INTEGER REFERENCES recipe (id) ON DELETE CASCADE ON UPDATE CASCADE ); CREATE TABLE recipe ( id INTEGER PRIMARY KEY, name TEXT ); INSERT INTO recipe (id, name) VALUES (1, 'yummy recipe'); INSERT INTO flavor (id, name, recipe_id) VALUES (1, 'flavor', 1); UPDATE recipe SET id = id + 1; SELECT * FROM flavor; -- 1|flavor|2

работает всё

1) CREATE TABLE recipe ( id INTEGER PRIMARY KEY, recipename TEXT, bottleid INTEGER, bottlesize INTEGER, pg INTEGER, vg INTEGER, nicotine INTEGER, date STRING, note TEXT ); CREATE TABLE flavor ( name TEXT, drops INTEGER, recipeid INTEGER REFERENCES recipe ON DELETE CASCADE );

recipeid INTEGER REFERENCES recipe ON DELETE CASCADE ); ссылаться просто на recipe?

или recipe(id)

ПОфиг

Это одно и то же

ON UPDATE CASCADE убери, не используй. Вообще никогда ключ не изменяй (update)

DELETE FROM ? WHERE ? какой должен быть

DELETE FROM recipe WHERE ..... (что угодно)

при recipeid INTEGER REFERENCES recipe(id) все удаляется. но у меня получаться recipeid завязан flavorid. как быть в таком случае

Он не завязан

Это иллюзия

Тут однонаправленная связь от recipe к flavor. Первый о втором ничего не знает.

Тут однонаправленная связь от recipe к flavor. Первый о втором ничего не знает.

Ну, неправ. Нет однонаправленных связей в SQL базах данных .

Но что у него там завязано я тоже не понял

при recipeid INTEGER REFERENCES recipe(id) все удаляется. но у меня получаться recipeid завязан flavorid. как быть в таком случае

Кто куда завязан?

Пример для одной записи. Если flavorid равен значению 386 и recipeid равен 386, нечего не удаляется, если recipeid равен 1, а flavorid 386 то все ок

1) CREATE TABLE recipe ( id INTEGER PRIMARY KEY, recipename TEXT, bottleid INTEGER, bottlesize INTEGER, pg INTEGER, vg INTEGER, nicotine INTEGER, date STRING, note TEXT ); CREATE TABLE flavor ( name TEXT, drops INTEGER, recipeid INTEGER REFERENCES recipe ON DELETE CASCADE );

Где ты тут вообще flavor ID видишь ?

Ну, неправ. Нет однонаправленных связей в SQL базах данных .

https://www.google.ru/search?q=unidirectional+relationship+database

Результатов: примерно 390 000 (0,50 сек.)

Результатов: примерно 390 000 (0,50 сек.)

Да мне похрн

Где ты тут вообще flavor ID видишь ?

ГДЕ

Да мне похрн

вот мы и обнаружили следующего президента

ddl CREATE TABLE recipe ( id INTEGER PRIMARY KEY, recipename TEXT, bottleid INTEGER, bottlesize INTEGER, pg INTEGER, vg INTEGER, nicotine INTEGER, date STRING, note TEXT, flavorid INTEGER );

@etkee , ты если со мной хочешь общаться, Запомни простое правило. Есть два мнения. ОДно моё, другое неправильное.

ddl CREATE TABLE recipe ( id INTEGER PRIMARY KEY, recipename TEXT, bottleid INTEGER, bottlesize INTEGER, pg INTEGER, vg INTEGER, nicotine INTEGER, date STRING, note TEXT, flavorid INTEGER );

В DDL что я прислал нет flavour_id

Если у тебя вкус ссылается на рецепт , никакой флейвор в рецепте не нужен

это как-то влияет

@etkee , ты если со мной хочешь общаться, Запомни простое правило. Есть два мнения. ОДно моё, другое неправильное.

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

@etkee , однонаправленная связь — это в ООСУБД, или в иерархических, сетевых, там связь в виде ссылки одного объекта на идентификатор другого. Вот там связи однонаправленные. ДВунаправленных нет — это две встречные однонаправленные. В РСУБД (БД) связей на самом деле вообще нет. Связи — это когда мы две записи связываем условием в запросе. Но если считать, что они есть, то они двунаправленные, потому что с обоих сторон связи можно выбрать другую сторону с помощью запроса.

Ещё вопросы есть ?

то есть внешних ключей не существует короче

FK это не связь, это констрейнт.

Он записывается с одной стороны (дочерней). Но связь при этом двунаправленная.

так есть связь или нет

Ну, вообще, философский вопрос...

Нет, но когда она нужна — есть. ?

я тоже в такие ответы ухожу, когда плаваю

Ладно, это на самом деле не очень поможет решению вопроса

это как-то влияет

На что?

/stat@combot

combot.org/chat/-1001045152752

Ты победитель

Ладно, это на самом деле не очень поможет решению вопроса

Я рад

Всем привет. Нужна помощь по MySQL. Есть две таблицы: