Как найти связанные элементы с разных таблиц?

Question

[AndroidRS]

Подскажите как найти связанные элементы с разных таблиц, если в одной из таблице не указанна связь.
Имеются таблицы:
1) wall - id, message, attachments
2) attachments - id, path

в таблице wall в поле attachments содержится id вложений и вся проблема заключается в том, что их может быть несколько штук (например: 1,324,5342). Подскажите пожалуйста как можно сопоставить значения или какие изменения внести в структуру таблиц, чтобы реализовать задумку более правильно?

Answer 1

[Rsa97]

FIND_IN_SET(`attachments`.`id`, `wall`.`attachments`) > 0

Но по уму надо приводить базу в нормальную форму, делать отдельную таблицу связи.

Comments

[AndroidRS]

Спасибо за ответ. Меня осенило, при загрузки файлов в attachments будет указываться parent_id = 0, а в момент создание записи, после того как станет известно id записи обновлять/привязывать данные (вложения) к публикацияи. Как думаете, это нормальный вариант или есть лучше?

[alexalexes]

Если у вас повторно используются вложения, то сама задача велит использовать третью таблицу, как вам советовали выше.
3) wall_attachments - id, wall_id, atach_id.
Если нет необходимости повторно использовать вложения, то достаточно атрибута внешнего ключа в табилце вложений.
attachments - id, wall_id, path
PS: наименование parent_id используется, как правило, для ссылки на записи той же таблицы, это для описания древовидных структур подходит.

[AndroidRS]

alexalexes, извиняюсь заранее, я не особо силен в mysql, поэтому я не понимаю, что это мне даст. Каждое вложение уникально и может использоваться только в одной публикации. Не пойму как мне потом объединить все в одно единое, структура на подобие этого:
- id
- message
attachments
-attachments_id
-attachments_path
(! Учитывая, что у каждой записи разное количество вложений (от 0 до 6)

(пример конечно результата, это api vk.com, метод wall.get https://vk.com/dev/wall.get (голову сломал уже)

[alexalexes]

Структура у вас такая будет:
1) wall - id, message
2) attachments - id, wall_id, path
где wall_id ссылается на запись таблицы wall.
Проблема в том, что если вы хотите сохранять записи вложений первыми, то вы не знаете какой вставить wall_id.
Есть куча вариантов как это решить.
Вариант 1.
Когда создается сообщение, клиент отправляет сразу и сообщение и вложения.
Тут сложностей со вставкой нет. Сохраняем запись wall, получаем его wall_id, используем для вставки вложений.
Вариант 2.
Мы не можем создать "честную" запись wall сразу, не отправив заранее записи вложений.
Решений варианта 2 первое.
Сохраняем записи вложений с опущенным параметром wall_id, например wall_id приравниваем null.
Когда добавляем запись wall, то известный wall_id вписываем в записи вложений, где было null.
Но учтите, если в вашей системе будет несколько пользователей, то нужно как-то различать, какой пользователь или сеанс пользователя мусорит несвязными записями вложений во время редактирования сообщения.
Для этого в таблице вложений должен использоваться дополнительный атрибут, указывающий на user_id или на его сеанс session_id, так:
attachments - id, wall_id, user_id, path
или так:
attachments - id, wall_id, session_id, path
И при связывании нужно брать не просто wall_id is null записи, а указывать, что брать нужно записи конкретного пользователя или сеанса.
Если пользователь бросил редактирование сообщения без сохранения, и при этом он оставил какие-то несвязные записи, то в вашей системе нужно предусмотреть скрипт, который будет периодически подчищать несвязные записи.
Для определения давно ли добавили записи, чтобы удалять сильно устаревшие, в таблице вложений нужно предусмотреть атрибут даты и время создания вложения. Чтобы можно было легко написать запрос, который подчистит эти старые записи, учитывая их время создания.
Решение варианта 2 второе.
Создаем временную запись wall, как только пользователь запросит форму создания сообщения.
Те же проблемы отслеживания временно созданной записи wall и пути решения такие же как в случае несвязных вложений.

[AndroidRS]

alexalexes, спасибо большое, так и поступлю. Я загружаю медиа файлы первыми, потому, что это api для мобильного приложения и это просто необходимо.