Laravel по-русски
Laravel по-русски
Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Страницы 1
Всем привет!
Есть 3 таблицы (T1, T2 и T3).
T1:
id_t1 - первичный ключ,
id_t2 - внешний ключ из T2,
прочие столбцы.
T2:
id_t2 - первичный ключ,
прочие столбцы.
T3 (имеет составной первичный ключ):
id_t2 - первичный ключ, внешний из T2,
num1 - первичный ключ,
num2 - первичный ключ,
id_t1 - внешний ключ из T1,
st - обычный столбец.
Созданы две модели для T1 и T2.
Подскажите, как правильно отразить все эти зависимости в Laravel?
Не в сети
Мастер 
Не в сети
}%модели в ларавель не поддерживают составные первичные ключи. я в таких случаях делаю обычные инкрементальные id-шники и добавляю уникальный индекс по нужным полям.
Вот статья на обход этого (после её прочтения, собственно, и появились такие ключи и в моей бд)) http://blog.artdevue.com/laravel-4-comp … y-key.html
}%кроме того, в постановке задачи отсутствует собственно описание отношений. где один ко многим? где один к одному? ничего не понять.
Т1 относится к одному Т2, Т2 имеет много Т1. Но этой связи в моем случае не достаточно, ибо тогда я получаю беспорядочный список Т1, относящихся к конкретному Т2. А в Т3, по сути, отражена та же связь между Т1 и Т2, только с уточнениями через столбцы num1 и num2. Таким образом, на запрос списка всех Т1 для каждого конкретного Т2 (через Т3, разумеется) я получу:
id Т2| num1| num2| id T1
2 1 3 1
2 2 3 2
3 1 3 3
3 2 3 4
3 2 4 5
Не в сети
Мастер
- Вот статья на обход этого (после её прочтения, собственно, и появились такие ключи и в моей бд)) [blog.artdevue.com]
не хочу показаться грубым, но эта статья — эпическая чушь. во-первых, то что описывает её автор вообще не должно быть в моделях. у него отношение многие-ко-многим между продуктами и материалами с дополнительными полями в отношении. по сути обычная пивот-таблица, в ларе есть апи для обращения к данным пивот-таблиц. в такой таблице иметь составной ключ можно и нужно. но автор идёт дальше и объявляет PHP$primaryKey = array( ... );, причём особой эпичности добавляет оставленный им phpDoc в котором тип указан как integer (на самом деле — string). если внимательно посмотреть в код модели, то становится очевидно, что PHP$primaryKey используется в контексте, исключающем возможность использования массива. но как я уже говорил, таблица автора и не должна была быть моделью вообще.
Не в сети
Мастер Т1 относится к одному Т2, Т2 имеет много Т1. Но этой связи в моем случае не достаточно, ибо тогда я получаю беспорядочный список Т1, относящихся к конкретному Т2. А в Т3, по сути, отражена та же связь между Т1 и Т2, только с уточнениями через столбцы num1 и num2. Таким образом, на запрос списка всех Т1 для каждого конкретного Т2 (через Т3, разумеется) я получу:
id Т2| num1| num2| id T1
2 1 3 1
2 2 3 2
3 1 3 3
3 2 3 4
3 2 4 5
T1 belongsTo T2
T2 hasMany T1
num1 и num2 должны быть столбцами в T1
Не в сети
T1 belongsTo T2
T2 hasMany T1
num1 и num2 должны быть столбцами в T1
Нет, нужно соблюдать уникальность комбинации значений из столбцов num1 и num2 для пользователя (т.е. у множества пользователей может быть комбинация num1=4; num2=23, но для каждого пользователя из этого множества эта комбинация встречается только один раз). В действительности num1 и num2 принимают значения от 1 до 5 и от 1 до 30 соответственно , поэтому создавать отдельные таблицы для них не стала, иначе было бы так:
id_num|value_num|
1 1
2 2
и т.д.
Но, судя по всему, раз ларавел не знает, что такое составной первичный ключ (как такое можно было допустить вообще...), придётся вынести num1 и num2 в отдельные таблицы, и тогда Т3 станет обычной pivot-table с двумя ещё полями - id_t1 и st.
Не в сети
Мастер constb пишет:T1 belongsTo T2
T2 hasMany T1
num1 и num2 должны быть столбцами в T1Нет, нужно соблюдать уникальность комбинации значений из столбцов num1 и num2 для пользователя (т.е. у множества пользователей может быть комбинация num1=4; num2=23, но для каждого пользователя из этого множества эта комбинация встречается только один раз). В действительности num1 и num2 принимают значения от 1 до 5 и от 1 до 30 соответственно , поэтому создавать отдельные таблицы для них не стала, иначе было бы так:
id_num|value_num|
1 1
2 2
и т.д.
Но, судя по всему, раз ларавел не знает, что такое составной первичный ключ (как такое можно было допустить вообще...), придётся вынести num1 и num2 в отдельные таблицы, и тогда Т3 станет обычной pivot-table с двумя ещё полями - id_t1 и st.
тебе не нужен пивот если отношения один-ко-многим. обеспечение уникальности можно гарантировать добавив уникальный индекс по (user_id, num1, num2)
Не в сети
тебе не нужен пивот если отношения один-ко-многим. обеспечение уникальности можно гарантировать добавив уникальный индекс по (user_id, num1, num2)
Не не не. Между T2 и num1, T2 и num2 - многие-ко-многим. И у этой комбинации часто будут меняться T1. Комбинаций num1 и num2 чётко прописанное количество, и это количество существует для каждого пользователя (т.е. вообще можно после создания новой строки в T2 сразу создавать строки id_t2|num1|num2|id_t1|st, где id_t2=id новой записи в T2, id_t1 и st =NULL), поэтому нельзя относить их в T1 в виде атрибутов T1.
Короче говоря, раз первоначальный вариант не подходит в рамках ларавела, тогда помимо T1 и T2 будут NUM1 (id_num1, num1) и NUM2 (id_num2, num2). А T3 будет:
T3 (имеет составной первичный ключ):
id_t2 - первичный ключ, внешний из T2,
num1 - первичный ключ, внешний из NUM1,
num2 - первичный ключ, внешний из NUM2,
id_t1 - внешний ключ из T1,
st - обычный столбец.
В таком случае, таблица будет связующей между T2, num1 и num2 (pivot-table с pivot-полем st) и иметь связь T3 hasMany T1, T1 belongsTo T3. И сохраняется связь T1 belongsTo T2, T2 hasMany T1.
У меня вопрос в другом теперь. Как в параметрах belongsToMany указать более двух первичных ключей?
Не в сети
Мастер Не в сети
Про модель я уже поняла, но я же написала про belongsToMany, это же не модель, а pivot-table для связи более двух моделей в одном месте... И что же, pivot таблицы ларавел понимает только с двумя ключами, только для двух моделей? Не более что ли?
Не в сети
Мастер Про модель я уже поняла, но я же написала про belongsToMany, это же не модель, а pivot-table для связи более двух моделей в одном месте... И что же, pivot таблицы ларавел понимает только с двумя ключами, только для двух моделей? Не более что ли?
в пивот-таблице вообще неважно первичный там ключ или простые индексы. обращение к дополнительным атрибутам пивот-таблицы идёт через свойство pivot модели. об этом есть в доке по eloquent.
Изменено constb (12.03.2015 13:31:05)
Не в сети
Читала я доки, нигде не нашла примера связи при помощи belongsToMany более двух моделей.(
Изменено vorobei (12.03.2015 17:36:40)
Не в сети
Мастер я по прежнему не понимаю откуда там связь на трёх моделях взялась. нутром чую неправильно спроектированную структуру базы, но в таком абстрактном описании не могу понять что не так.
Не в сети
Страницы 1
Универсальная вики-разметка
Работает на FluxBB (перевод Laravel.ru)