Управление пользователями при использовании автономной базы данных в качестве поставщика членства

Question

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

Любые указатели высоко ценится

Answer 1

Я тоже заинтересован в этом. Это, вероятно, не квалифицируется как ответ - но я обновлю, как только я реализовал.

Я также использую поставщик членства ASP.NET с моим веб-приложением; хотя я включил в свою базу данных таблицы SQL и Procs для поставщика членства, я сохранил логическое разделение, чтобы вы могли запускать его отдельно, если хотите.

Несмотря на то, что вы сосредоточились на проблемах с базой данных (что вполне справедливо), важно помнить, что с помощью поставщика членства ASP.NET вы имеете дело не только с базой данных. Особенность поставщика членства ASP.NET заключается в самом поставщике - фактическое хранилище данных абстрагировано.

Я предполагаю, что с провайдером членства ASP.NET я смогу использовать службы / API самого провайдера, чтобы помочь управлять судами отношений, о которых вы говорите. Поэтому я не буду полагаться конкретно на базу данных - потому что «провайдер» - это внешний интерфейс, через который я должен пройти, и его использование привязало бы меня к этому источнику данных.

Answer 2

"если я просто использую идентификатор в базе данных членства, я не могу ссылаться на сообщения пользователя по внешнему ключу"

Здесь возникает проблема принудительное применение иностранногоключ .Я не знаю ни одной СУБД, которая поддерживает внешние ключи, которые ссылаются на таблицу через ссылку на базу данных.И даже если бы это было возможно, было бы желательно?Такое расположение означало бы, что мы не можем вставить дочерние записи в нашу локальную базу данных, если удаленная база данных по какой-либо причине отключена.

Обычным обходным решением в таком сценарии является репликация, то есть сохранение копииудаленная таблица в локальной базе данных.Если у нас есть СУБД, которая поддерживает удаленные материализованные представления, это может быть довольно простой реализацией.