Флаги в базе данных строки, лучшие практики

Как будто вы пытаетесь получить доступ к объекту, который является null. Рассмотрим ниже пример:

TypeA objA;

. В это время вы только что объявили этот объект, но не инициализировали или не инициализировали. И всякий раз, когда вы пытаетесь получить доступ к каким-либо свойствам или методам в нем, он будет генерировать NullPointerException, что имеет смысл.

См. Также этот пример:

String a = null;
System.out.println(a.toString()); // NullPointerException will be thrown
35
задан Evan Teran 30 July 2014 в 17:02
поделиться

7 ответов

Если Вам действительно нужен неограниченный выбор от замкнутого множества флагов (например, stackoverflow значки), то "реляционный путь" состоял бы в том, чтобы составить таблицу флагов и отдельную таблицу, которая связывает те флаги с Вашими целевыми объектами. Таким образом, пользователи, флаги и usersToFlags.

Однако, если бы эффективность пространства является серьезным беспокойством и способностью запроса, не, неподписанная маска работала бы почти также.

27
ответ дан Daniel Spiewak 27 November 2019 в 06:56
поделиться

Для многих случаев это зависит от большого количества вещей - как Ваш бэкенд базы данных. При использовании MySQL, например, , тип данных НАБОРА точно, что Вы хотите.

В основном, это - просто битовая маска со значениями, присвоенными каждому биту. MySQL поддерживает до 64-разрядных значений (значение 64 различных переключателей). Если Вам только нужно 8, то это только берет байт на строку, которая является довольно потрясающими сбережениями.

, Если у Вас честно есть больше чем 64 значения в единственном поле, Ваше поле могло бы становиться более сложным. Можно хотеть расшириться тогда до типа данных BLOB, который является просто необработанным набором битов, из которых MySQL не имеет никакого свойственного понимания. Используя это, можно создать произвольное число битовых полей, которые MySQL рад рассматривать как двоичный файл, шестнадцатеричное число или десятичные значения, однако Вам нужно. Если Вы нуждаетесь больше чем в 64 опциях, создаете столько полей, сколько подходит для Вашего приложения. Оборотная сторона, это, является трудным сделать поле человекочитаемым. Тип данных bit также ограничен 64.

5
ответ дан aneroid 27 November 2019 в 06:56
поделиться

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

реляционное решение было предложено ранее. Учитывая пример Вы обрисовали в общих чертах, я создам что-то вроде этого (в SQL Server):


CREATE TABLE Users (
  UserId INT IDENTITY(1, 1) PRIMARY KEY,
  FirstName VARCHAR(50),
  LastName VARCHAR(50),
  EmailAddress VARCHAR(255)
);

CREATE TABLE Badges (
  BadgeId INT IDENTITY(1, 1) PRIMARY KEY,
  [Name] VARCHAR(50),
  [Description] VARCHAR(255)
);

CREATE TABLE UserBadges (
  UserId INT REFERENCES Users(UserId),
  BadgeId INT REFERENCES Badges(BadgeId)
);
29
ответ дан Jeremiah Peschka 27 November 2019 в 06:56
поделиться

Если флаги имеют совсем другие значения и используются непосредственно в SQL-запросах или ПРЕДСТАВЛЕНИЯХ, то использование нескольких столбцов типа BOOLEAN могло бы быть хорошей идеей.

Помещенный каждый флаг в дополнительный столбец, потому что Вы считаете и измените их отдельно так или иначе. Если Вы хотите сгруппировать флаги, просто дайте их именам столбцов общий префикс, т.е. вместо:

CREATE TABLE ... (
    warnings INTEGER,
    errors   INTEGER,
    ...
)

необходимо использовать:

CREATE TABLE ... (
    warning_foo BOOLEAN,
    warning_bar BOOLEAN,
    warning_...
    error_foo   BOOLEAN,
    error_bar   BOOLEAN,
    error_...   BOOLEAN,
    ...
)

, Хотя MySQL не имеет БУЛЕВА типа, можно использовать квази стандартный TINYINT (1) с этой целью и установить его только на 0 или 1.

3
ответ дан vog 27 November 2019 в 06:56
поделиться

А Очень Реляционный Подход

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

, Например, для Таблицы "Студенты" у Вас могли быть таблицы "RegisteredStudents", "SickStudents", TroublesomeStudents и т.д. Каждая таблица будет иметь только один столбец: student_id. Это на самом деле было бы очень быстро, если все, что Вы хотите знать, - какие студенты "Регистрируются" или "Больны", и работали бы тот же путь в каждом DBMS.

4
ответ дан Seun Osewa 27 November 2019 в 06:56
поделиться

Я рекомендовал бы использовать булев тип данных если Ваша поддержка БД это.

Иначе, лучший подход должен использовать НОМЕР (1) или эквивалент, и помещать проверочное ограничение на столбец, который ограничивает допустимые значения (0,1) и возможно ПУСТОЙ УКАЗАТЕЛЬ, если Вам нужно это. Если нет никакого встроенного типа, использование числа менее неоднозначно что с помощью символьного столбца. (Каково значение для истинного? "T" или "Y" или "t")

хорошая вещь об этом состоит в том, что можно использовать СУММУ () для подсчета количества строк TRUE.

SELECT COUNT(1), SUM(ActiveFlag)
FROM myusers;
3
ответ дан WW. 27 November 2019 в 06:56
поделиться

Если будут больше, чем всего несколько флагов, или вероятно быть так в будущем, я буду использовать отдельную таблицу флагов и many-many таблицу между ними.

, Если существует горстка флагов и я никогда не собираюсь использовать их в, ГДЕ, я буду использовать НАБОР () или битовое поле или что бы то ни было. Их легко считать и более компактный, но боль для запросов и иногда еще больше головной боли с ORM.

, Если существует только несколько флагов - и только когда-либо движение , чтобы быть несколькими флагами - тогда, я просто сделаю пару столбцов BIT/BOOLEAN/etc.

1
ответ дан Eevee 27 November 2019 в 06:56
поделиться
Другие вопросы по тегам:

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