2011-01-19 2 views
0

Я создаю приложение mvc 3, которое будет многожильным, что означает, что он будет использовать одну и ту же базовую структуру данных, но предоставлять разные данные в зависимости от имени домена, используемого для доступа к нему.Заполнение dropdownlists для приложений с множеством арендаторов

Проблема, которую я пытаюсь решить, это. Как лучше всего заполнить несколько выпадающих списков с выбором выбора на основе отображаемого сайта. Чтобы добавить еще одну морщину, мне также необходимо локализовать строки.

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

В качестве примера у сайта 1 может быть раскрывающийся список для избранных занятий, а также элементы диапазона, ориентированные на музыкальные интересы. Сайт 2 может иметь одинаковое раскрывающееся меню, но есть предметы, предназначенные для спортивных соревнований.

Так что мой вопрос: как бы вы решили решить эту проблему? Кроме того, в том же ключе ... Если у вас есть списки выбора, например, коды штата, города и т. Д., Вы бы хотели создать отдельные таблицы для заполнения этих данных (таблица состояний, таблица городов и т. Д.) Или вы бы поставили всю эту информацию в общей таблице и иметь идентификатор, чтобы указать, какой выпадающий список должен был использоваться? Первое кажется более нормализованным, но последнее кажется более эффективным (меньше кода для написания).

+0

Я не думаю, что это имеет какое-либо отношение к asp.net-mvc. Multi-tenantcy - довольно язык, агностик, и то, что ваш вопрос больше связан с вопросом проектирования данных. – jfar

+0

Это связано с asp.net-mvc из-за аспектов локализации и того, какие методы локализации предоставляются asp.net-mvc. Кроме того, это связано с тем, как заполняются ниспадающие списки, что отличается от MVC в сравнении с другими структурами. –

ответ

1

Мысли о таблицах общего поиска. Этот парень определенно против.

http://www.projectdmx.com/dbdesign/lookup.aspx

Я использовал его и считаю, что я накопил некоторое время, или, по крайней мере, некоторые нажатия клавиш. Может быть, извините позже.

+0

У него есть интересные комментарии. Я не согласен с некоторыми из них, или, вернее, я считаю, что они слишком теоретичны. Однако он делает некоторые хорошие моменты. Это разделение в дизайне базы данных между пуристами и прагматиками. Пуристы верят в высоко нормированные данные, с естественными ключами. На практике технология часто затрудняет этот подход. Кроме того, пуристы склонны думать о моделях данных как о моделировании реальной жизни, но некоторые модели данных должны идти на уступки (например, быть расширяемыми или решать проблемы с несколькими арендаторами). –

+0

Ссылка больше недоступна, так что ответ действительно не действительный. –

Смежные вопросы