sender219... есть такая идея: прокинуть поле ссылки на таблицу "A" по всем "подчинённым" таблицам, затем триггером проставлять значения (поднимаясь по всей схеме) при вставке.
Идея бредовая. Одно дело если пользователей до 100. А если их больше?.. А их будет больше, просто об этом еще никто незнает.
Создание правильных индексов значительно облегчает жизнь.

sender219,

Может я конечно и несовсем правильно понял (было б немлохо схему посмотреть), но в идее предлагается инсерт (триггером или скриптом - не столь важно) по объектам конкретного пользователя. Т.е. если в системе будет 3 пользователя то максимум одновременного инсерта - 3, если 100 то 100, ... Таким образом чем больше пользователей в системе тем выше шанс увеличения нагрузки при инсертах.
Собственно в примере с заказом вполне разумно держать в таблице заказа поле пользователя, а не вытягивать его через ...

На самом деле незная целей и задач, не видя так сказать всей картины - сложно что-то утверждать. Поэтому абсолютно все вышесказанное относится к гаданию на кофейной гуще. Так что или автор попробует "разжевать", или пусть выбирает из "потока" то что ему нужно.

sender219,

Блин. Или я туплю или ... А описание модели где? Или это озвученное выше "Пользователи - Поставщики - Поставки - Заказы (клиентские)" ?
Если озвученное выше то уберите из providers user_id. Сделайте таблицу providers_user (provider_id, user_id, ...). Можете в нее еще добавить дату начала и дату конца, тогда сможете организовать историю изменения пользователя для данного поставщика. В таблице orders поле purchase_id явно лишнее, можете смело убирать.
И если приводите схему то отображайте все элементы таблиц, это избавит от непоняток (в данном случае я непытаюсь угадать что у вас там еще скрыто).

sender219Злой Бобр...Сделайте таблицу providers_user (provider_id, user_id, ...)...
Зачем? Если отношение между ними 1-М, зачем мне переходить на М-М?
По условию поставщик принадлежит только одному пользователю. И у одного пользователя может быть много собственных (личных) поставщиков.
Зачем - я написал выше (что б видеть историю если у поставщика меняется пользователь). Но если вас устраивает что при изменении пользователя вы тупо перепишите поля таблицы (вместо Петров напишете в ФИО Сидоров) - невопрос, это ваша кухня и вам там рулить. Если считаете что пользователь будет жить вечно - это тоже ваше дело.
Я вовсе не претендую на мнение последней инстанции. Все что тут пишется носит лишь рекомендательный характер. Конечный выбор за вами.
sender219Злой Бобр...В таблице orders поле purchase_id явно лишнее, можете смело убирать...
А это зачем? Если по каждой поставке (purchases) может быть ноль или М заказов (orders).
В целом картина такова: каждый пользователь системы ведёт собственный каталог поставщиков. По каждому своему поставщику пользователь формирует поставки. По каждой поставке может быть сформировано М заказов.
Ну тогда я неправильно понял смысл поставки. У вас это оказывается сводный заказ по клиентам, а я "телепартировал" что это аналог Партии. Увы, отсутствие описания дает подобные казусы.
sender219Злой Бобр...И если приводите схему то отображайте все элементы таблиц, это избавит от непоняток (в данном случае я непытаюсь угадать что у вас там еще скрыто).
Скрыты атрибуты, не имеющие отношения к вопросу. Свойства пользователя, поставщика и т.д.
Опять же это лишь рекомендация. Хотите удивляться почему вам рекомендуют то что явно невписывается в вашу задачу - можете и дальше вырывать куски из контекста, а мы будем "телепартировать".