Хранилище в DB или не сохранить?
Существует немного списков строк в моем веб-приложении, которое я не знаю, где сохранить в DB или просто классе.
т.е. у Меня есть 7 главных браузеров, с которыми пользователи вводят сайт. Я хочу сохранить эту статистику таким образом, я должен создать столбец браузера в базе данных UserLogin. Я не хочу тратить впустую пространство и ресурсы, таким образом, я могу сохранить полное имя браузера в каждой строке входа в систему. Таким образом, я или должен сохранить browserID поле и поднять трубку его с таблицей Browsers, которая будет названия магазина после правил нормализации дб или иметь вид абстрактного класса Dataholder, который имеет список браузеров, от которых я могу получить имя браузера, он - идентификатор...
Вопрос, что я должен сделать? Эти немного списков данных, которые я имею, содержат не больше, чем 200 объектов каждый так, что я думаю, что имеет смысл иметь их как абстрактный класс, но снова я не знаю, обработает ли MS-SQL несколько соединений так хорошо. Думайте об идее, когда у меня будет пользователь со страной, IP, языком, браузером и еще небольшим количеством статистики..
спасибо
2 ответа
Я был по обе стороны забора по этому вопросу.
Мое эмпирическое правило таково:
Если один из этих списков изменится, придется ли мне вносить изменения и в код?
(например: в вашем случае, если кто-то завтра напишет "еще один браузер", придется ли мне писать код, который будет его обслуживать?)
Если ответ "скорее всего да" или "определенно", вы можете оставить его в коде. Во всех остальных случаях (даже просто "возможно, 50%-50%") лучше поместить это в БД, или, по крайней мере, в файл свойств.
И, пожалуйста, примите во внимание следующее: если вы ожидаете, что вам придется предоставлять статистику, основанную на этих данных (например, "сколько пользователей используют Explorer"), вам в любом случае лучше поместить их в DB: они становятся частью данных вашего домена и поэтому должны быть там.
О части "доменных данных".
Информация, хранящаяся в вашей БД, является "доменными данными" вашего приложения. Это, в некотором смысле, (надеюсь, последовательное) представление того, о чем ваше приложение - оно представляет собой "известную вселенную" для вашего приложения. Если вы согласны с этим определением, то вы также должны принять, что не имеет смысла иметь 99,9% вашей "реальности" в БД, а 0,1% вне ее - если не более того, это делает некоторые операции громоздкими (если вы храните только smallint, вы не сможете создавать значимые отчеты, не обрабатывая их с помощью класса для декодирования "1" в "Firefox" или предоставляя другой ключ для конечного пользователя). Это также делает невозможным использование некоторых присущих БД техник, таких как внешний ключ (если вы просто используете smallint, не соотнося его с какой-либо другой таблицей, кто гарантирует, что "10" является приемлемым значением в вашей области?)
.MS SQL очень хорошо обрабатывает множественные соединения; Вам решать, где вы хотите хранить данные. Вы также можете рассмотреть XML как еще один вариант. Я бы рассмотрел базу данных или XL; легче изменить значения, чем если бы значения были в коде (необходимо перекомпилировать / развернуть, чтобы изменить в производственной среде).
HTH.