2010-01-28 2 views
0

Я пишу приложение .net, которое принимает информацию о форме, чтобы сделать некоторые предварительные квалификационные оценки автокредитов и сохранит это в базе данных. Проблема заключается в том, что каждое поле должно позволять пользователю вводить в него любые строковые данные и сохранять их в базе данных.Как сохранить данные, которые можно получить?

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

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

Последнее, что я подумал о сохранении одного дополнительного столбца или таблицы, который будет просто парой значений имен, чтобы поместить все данные, недоступные для этой записи. Я думаю, что это может быть очень сложно создать бизнес-объекты.

Как вы относитесь к этому вопросу?

+5

Почему каждое поле позволяет пользователю вводить любые строковые данные * и * сохранять точные данные в базе данных? ИМО, это непродуманное требование, которое вернется, чтобы укусить вас в конце, так или иначе. – Aaronaught

+0

Я не думаю, что это непродуманное требование - есть очень веские причины, чтобы хранить то, что клиент набирает в веб-форме, и другие очень веские причины для того, чтобы захотеть проанализированная версия полезных данных для обработка. –

ответ

0

Я думаю, что ваше предложение использовать два столбца для каждого поля - лучший подход. Ведь это семантически то, что происходит.

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

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

+1

Хранение плохих данных и наделение на автоматическую очистку позже, а не представление каких-либо выявляемых проблем для пользователя во время ввода, является (... вежливо ...) субоптимальным. – ErikE

+0

Это не то, что я предлагаю, или то, что он просит. Я предлагаю сохранить исходный вход и проанализированные данные. Данные действительно должны быть проанализированы немедленно. – Tomas

0

Я предполагаю, что вам нужно сохранить то, что пользователь вводит для правильной записи, ну, что пользователь набрал. Итак, это одна строка в поле под названием «what_the_user_typed». Это может привести к множеству столбцов в вашей таблице, но что это за черт. Затем, какие полезные данные вы можете (или вы хотите) проанализировать из этой строки? Я бы предположил об одном значении для каждой строки. Если, например, у вас есть поле с надписью «Age of Car», вы можете проанализировать строку «age_of_car» или, даже, «year_of_first_registration»; так что это еще один столбец для таблицы. И так далее.

1

только разумный способ кустарником данных , когда он вошел, когда человек со знанием, чтобы исправить это на самом деле присутствует.

Таким образом, в ваших веб-форм:

  1. Использование Javascript для предотвращения попадания недопустимых символов.
  2. Используйте javascript для проверки полей перед отправкой их на сервер, а затем отобразите заметки о том, какие поля нуждаются в исправлении и как.
  3. И на сервере, проверьте все поля на достоверность и повторно отобразите веб-форму с примечаниями о том, какие поля нуждаются в коррекции и как.

Номер 3 важен, потому что если javascript отключен (или кто-то пытается взломать форму представления), форма и проверка будут по-прежнему работать должным образом.

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