2014-01-12 3 views
1

Я не думаю, что задаю вопрос правильно, но, надеюсь, вы знаете, о чем я прошу.Логическое мышление: использование динамических и статических значений для представления данных

Каковы преимущества и недостатки использования строкового значения для представления поля базы данных (или любой переменной) против использования перечисления или константы? Я не спрашиваю о типе данных, но его обрабатывает на задней панели. Для примера я использую LINQ to SQL.

Мое мышление заключается в том, что, используя перечислимое или постоянное, это: легче читать, обеспечивает совместимость, когда значения когда-либо должны быть изменены, а значение жестко закодировано - так сказать, - так что существует меньше шансов на ошибку вызванное опечаткой. С другой стороны, действительно ли мне нужен класс/структура с перечислениями членов, которые по существу действуют как поиск нужного значения?

Использование постоянного

Module Trip 
    Public Const OPEN As String = "Open" 
    Public Const PENDING_PAYMENT As String = "Pending Payment" 
    Public Const CANCELLED As String = "Cancelled" 
    Public Const CLOSED As String = "Closed" 
End Module 

Dim product = From p In db.Payments 
     Where p.PaymentId = PaymentId 

For Each item In product 
    item.Status = PayStatus.PENDING_PAYMENT 
Next 

Использование строки

Dim product = From p In db.Payments 
     Where p.PaymentId = PaymentId 

For Each item In product 
    item.Status = "Pending Payment" 
Next 
+1

Я не думаю, что это будет работать вообще, сначала доведите свой «item.Status» return 'String' ИЛИ' Byte'? если это String Тогда вы не можете сравнить его с байтом и наоборот. –

+0

Ya вы правы, не можете конвертировать nvarchar в float. Однако, что, если вместо Enum я использовал константы? Я обновлю свой код – KRob

+1

Почему бы не использовать таблицу поиска в базе данных для значений статуса? – Tim

ответ

1

Как один из комментариев, говорит, общий способ справиться с этим использует таблицу поиска в базе данных , В своей самой простой форме, вы бы иметь класс, скажем PaymentStatus:

Class PaymentStatus 
    Public Property Id As Integer 
    Public Property Name As String 
End Class 

и Payment бы ссылочный недвижимость как

Public Property PaymentStatus As PaymentStatus 

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

Например, подумайте, что вам нужно сделать, если вы решите, что «Отменено» необходимо дифференцировать в «Отмененный пользователем» (старый статус) и «Отменено системой» (новый статус, введенный новая бизнес-логика). Вам понадобится сценарий для обновления всех записей в базе данных до новой строки (и изменения кода, но вы все равно меняете код). Таблица поиска позволяет обновить только одну запись (и добавить новый в этом примере).

+0

Вы абсолютно можете сделать опечатку, потому что вам нужно как-то найти строку перечисления, представляющую отмененный статус. Я бы хотел увидеть список преимуществ использования таблицы enum, прежде чем я буду реализовывать такую ​​вещь. Кажется, что это наиболее полезно, если члены перечисления изменяются во времени. – usr

+0

@usr Правильно. В действительности я бы (и сделал) объединить это с типом перечисления. Но я никогда не буду использовать строковые литералы, когда они будут храниться повторно в базе данных, это главное. Я жду ответа OP, чтобы посмотреть, находимся ли мы на одной странице и, возможно, потребуется некоторое последующее наблюдение. –

+0

@ GertArnold С представлением о производительности - скажете ли вы, что это лучший способ или просто обычный способ? Преимущества, которые вы указали в таблице поиска, перевешивают производительность? Может ли быть заметен счет соединения таблицы с несколькими рядами? – KRob

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