Должен ли я использовать перечисление или запрашивать таблицу в моей базе данных?

В моей базе данных есть таблицы, которые определяют типы, например

Таблица: Типы публикаций

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)

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

Спасибо всем за ваши ответы. Теперь я могу действовать спокойно.