Должен ли я использовать перечисление или запрашивать таблицу в моей базе данных?
В моей базе данных есть таблицы, которые определяют типы, например
Таблица: Типы публикаций
ID | Type
----------
1 | Article
2 | Abstract
3 | Book
....
Что связано с ключом идентификатора с таблицами публикаций, которые имеют поле TypeID.
Затем я создаю таблицу данных PublicationTable для моего приложения .NET, которую я хочу фильтровать на основе типа публикации. Например, следующая функция дает мне количество публикаций для конкретного автора и типа публикации.
Public Function countPublications(ByVal authorID As Integer, _
ByVal publicationType As Integer) As Integer
Dim authPubs As New PublicationsDataSet.tblPublicationsDataTable
authPubs = Me.getAuthorsPublications(authorID)
Dim dv As New DataView(authPubs)
dv.RowFilter = "status='published' AND type='" + _
publicationType.ToString + "'"
Return dv.Count
End Function
Чтобы вызвать эту функцию, чтобы получить количество статей автором определенного типа, я мог бы
-
вызов функции с двумя целыми числами
countPublications (authorID, 1)
-
настройте перечисление, чтобы я мог писать
countPublications (authorID, pubType.Article)
или
-
каким-то образом использовать таблицу типов публикации для фильтрации набора данных публикации, но я не знаю, как это сделать.
Какие другие подходы следует рассмотреть.
Спасибо
Ответы
Ответ 1
если типы публикации по существу статичны, перечисления в порядке
возможно, мало различий между вложением
inner join lookuptable lt on lt.id = (int)myenum.sometype
в запросе и добавлении
inner join lookuptable lt on lt.name = "somehardcodeddescription"
они оба встроенные константы, у первого есть четко определенный тип за ним
поочередно вы можете использовать
inner join lookuptable lt on lt.name = myenum.sometype.ToString
Я предпочитаю первый
если, с другой стороны, новые типы запросов могут быть добавлены после развертывания кода, то перечисление быстро устареет;
но если есть набор основных значений статического enum, которые нужны коду, а остальное не имеет значения, то первое решение по-прежнему прекрасное.
как обычно, "это зависит"; -)
Ответ 2
Сохраняя подобные вещи в предыдущей жизни, я согласен с Стивеном, что enum
вполне разумен. Ваш код ясен, а enum
означает, что вам нужно обновлять только один файл, если вы добавляете типы данных.
Я также предложил бы комментировать enum
, давая понять, что значения должны соответствовать значениям в таблице Publication Types
в вашей базе данных.
Хороший вопрос, кстати! +1 для объяснения вопроса так ясно и время, потраченное на мозговой штурм решений перед публикацией.
Ответ 3
Я думаю, что это зависит от того, как часто ваш список типов публикаций будет изменяться в будущем, и о том, как легко вы можете нажать обновление вашего приложения. Если список не будет меняться часто или если обновление вашего приложения в поле легко, то перечисление имеет смысл. Если список, вероятно, будет часто меняться или если обновление вашего приложения особенно сложно, то сохранение списка в таблице в базе данных разумно.
Ответ 4
По различным причинам было бы неплохо вести списки, такие как список типа публикации и другие в одном месте; базы данных. Тогда есть только одно место для их изменения. Тем не менее, мне кажется, что это добавляет некоторую сложность коду, и мне все равно нужно будет иметь некоторые жестко закодированные элементы в коде, если бы я хотел ссылаться на определенный тип публикации, такой как Journal Articles. Поэтому, имея перечислимый тип, который отражает данные в таблице, дает мне возможность вызвать функцию подсчета читаемым образом
countPublications(authorID, publicationType.JournalArticle)
Если данные в таблице изменяются, что маловероятно, я могу получить комментарий в базе данных, чтобы напомнить сопровождающему (возможно, мне) об обновлении перечисленного типа в коде и наоборот.
Спасибо всем за ваши ответы. Теперь я могу действовать спокойно.