Дизайн данных - несколько коротких поездок против одной большой поездки

Question

Свернуто: Лучше ли возвращать вычисленное поле с остальными результатами или лучше вычислить его позже, когда оно понадобится?

Пример: У меня есть GridView, который отображает результаты поиска, который имеет много полей, таких как:

• Идентификатор приложения
• Имя
• Тип учетной записи
• Номер счета

и т.д.

Поле номера счета не всегда одно и то же. Для счетов типа A они имеют длину восемь цифр, а для счетов типа B - двенадцать.

После поиска, если они выбирают запись и выбирают продолжить приложение, мне нужно проверить номер учетной записи eigit для любых ограничений доступа. У всех учетных записей типа A и B есть связанный номер счета eigit, просто у типа B только двенадцатизначный номер.

Так следует ли мне добавить в результаты поиска лишнее скрытое поле, такое как "Общий номер счета", и просто скрыть его, в результате чего интенсивно используемый поиск займет немного больше времени, а таблица результатов займет больше места в состоянии просмотра?

или

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

Answer 1

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

Но, возможно, есть способ немедленно вернуть правильный набор результатов - например, вам нужно 8-значные числа на этом дисплее или вы могли бы сразу же вернуть 12-значнуюномера для счетов типа B?Если да, возможно, вы могли бы определить представление или сразу добавить вычисляемый столбец в вашу модель данных.Есть ли другой способ сохранить состояние, чтобы вы могли избежать скрытых полей?

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

Answer 2

Нет проблем с добавлением дополнительного скрытого столбца, особенно если у вас есть внутреннее приложение компании.

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