2013-05-20 2 views
0

Я создаю веб-приложение .net, которое будет включать проверку поля ввода электронной почты на список допустимых адресов электронной почты. Там может быть до 10 000 приемлемых значений, и они не будут меняться очень часто. Когда они это сделают, весь список будет заменен, а не отдельные записи.Таблица SQL Server или текстовый файл для редко изменяемых данных

Я обсуждаю лучший способ реализовать это. У нас есть база данных SQL Server, но поскольку эти записи будут относительно статичными и заменяться только навалом, я рассматриваю возможность просто ссылаться на текстовые файлы, содержащие строковые значения. Похоже, это упростит процесс загрузки, и мало пользы от этой информации в rdbms.

Отзыв оценен.

+2

Как правило, гораздо проще работать только с одним хранилищем данных, и поскольку вы уже используете SQL Server, я действительно не вижу никакой пользы в том, чтобы что-то помещать в файловую систему в веб-приложении .... даже если список электронных писем не меняется часто - просто положите его в таблицу и сделайте с ней! –

ответ

2

Если база данных уже есть, используйте ее. То, о чем вы говорите, именно то, что предназначены для работы с базами данных. Если по дороге вы решили, что вам нужно сделать что-то немного сложнее, вы будете очень рады, что вы пошли с БД.

+1

+1 точно - если эта база данных уже существует и используется - в чем смысл игнорировать ее и использовать что-то еще? –

0

Я собираюсь сделать несколько предположений о вашей ситуации.

  1. В вашем наборе данных содержится более 1 столбца пригодных для использования данных.
  2. Ваш рекорд показывает больше строк, чем будет всегда дисплей.
  3. Ваши данные должны быть отформатированы в виде вида вывода (например, HTML).

Вот некоторые конкретные причины, почему ваши полустатичный данные должны остаться в SQL, а не в текстовом файле.

  1. Вам не придется анализировать текстовые данные каждый раз, когда вы хотите их прочитать и обработать. (Синтаксический разбор строки является относительно большой памятью и загрузкой процессора). SQL будет хранить ваши столбцы как структурированные данные, которые предварительно анализируются.
  2. Вам не придется разрабатывать собственный алгоритм фильтрации строк или поиска (или реализовать библиотеку, которая сделает это для вас). SQL уже является сложным механизмом, который применяет передовые алгоритмы кэширования, оптимизацию запросов (со многими лежащими в основе расширенными алгоритмами поиска/поиска/сканирования/индекса/хеша/и т. Д.).
  3. У вас есть возможность с SQL расширить возможности вашего решения и интеграция с другими инструментами с течением времени. (Помещение данных в текстовый или XML-файл ограничит будущие возможности).

Предостережения:

  • Ваша реализация частности SQL Server может повлиять на диск IO и производительности сети латентности. Для настройки производительности ввода-вывода диска хорошо построенный SQL Server размещает файлы данных (.mdf) на быстрых массивах дисков с несколькими шпинделями, настроенных для быстрого чтения, и отделяет их от файлов журнала ( .log) на шпинделях, которые настроены для быстро пишет.
  • Возможно, вы обнаружите, что латентность и занятость (а не слово) SQL-сервера могут повлиять на производительность. Если вы работаете на очень занятом или медленном SQL-сервере, вы можете оказаться в ситуации, когда вы будете искать альтернативу локального файла, и в этом случае я бы рекомендовал структурированный формат, например XML. (Однако, если вы обнаружите, что ищете работу, чтобы избежать использования вашего SQL-сервера, было бы лучше потратить некоторое время/деньги на улучшение вашей реализации SQL.
+0

Спасибо. Цените анализ. Это всего лишь один столбец данных ... пока. Думаю, это может измениться, хотя – user2391532

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