Дизайн таблицы базы данных “Пользовательских настроек”

Question

Дизайн таблицы базы данных “Пользовательских настроек”

Сохраните «нежелательные» отфильтрованные данные в вспомогательном объекте Range, отфильтруйте и покажите все свои данные, скройте вспомогательный диапазон, наконец установите для него видимые данные

Dim myRng As Range
With wsDB 
    With Range("J10", .Cells(.Rows.Count, 1).End(xlUp))
        . AutoFilter Field:=2, Criteria1:=Array("T8932", "TR8434", …………)
        Set myRng = .Offset(1).Resize(.Rows.Count - 1). SpecialCells(xlCellTypeVisible)
        .Parent.AutoFilterMode = False
        myRng.EntireRow.Hidden = True
        Set myRng = .Offset(1).Resize(.Rows.Count - 1). SpecialCells(xlCellTypeVisible)
    End With 
End With

5

database-design sql-server-2005 database asp.net

задан NSX 28 February 2009 в 23:20

4 ответа

Другие вопросы по тегам:

database-design sql-server-2005 database asp.net

Похожие вопросы:

score 3 · Answer 1

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

Теперь, если Вы будете видеть, что эти предпочтения используются в какой-либо другой форме или виде в Вашей базе данных, как несколько объектов (не только пользователи) использование тех же предпочтений, то затем Вы захотите спуститься по своему второму маршруту и сослаться на предпочтения с парами FK/PK.

Что касается того, что Вы описали, я не вижу оснований, почему первый маршрут не будет работать.

score 2 · Answer 2

При хранении всех пользовательских настроек в одной строке таблицы User, у Вас будет кошмар обслуживания!

Используйте одну строку на предпочтение, на пользователя и сохраните предпочтительное значение как varchar (длина 255 говорят, или некоторое значение, достаточно большое для соответствия требованиям). Необходимо будет преобразовать значения в/из этом столбце, очевидно.

Единственная ситуация, где это не будет работать легко, состоит в том, если Вы хотите хранить некоторые большие двоичные данные как Пользовательскую настройку, но я не нашел что быть общим требованием.

score 2 · Answer 3

Я обычно делаю это:

Users table (user_id, .... etc.)
.
Options table (option_id, data_type, ... etc.)
(list of things that can be set by user)
.
Preferences table (user_id, option_id, setting)

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

score 0 · Answer 4

Реальный быстрый, один метод:

User(UserID, UserName, ...)

PreferenceDataType(PreferenceDataTypeID, PreferenceDataTypeName)

PreferenceDataValue(PreferenceDataValueID, PreferenceDataTypeID, IntValue, VarcharValue, BitValue, ...)

Preference(PreferenceID, PreferenceDataTypeID, PreferenceName, ...)

UserHasPreference(UserID, PreferenceID, PreferenceDataValueID)