Не используйте неподходящие типы данных - просто сохраняйте даты как даты; числа как числа; и строки в виде строки.

тим, у меня есть таблица в Oracle 12c со столбцами:

create table t1 (
a number (5,0),
b varchar (5,0)
d ...
e ...
);

Затем я вставляю 100 000 000 записей в оба столбца, которые имеют одинаковые значения - например,

20151 and '20152' ... (for a first record)
20152 and '20152' ... (for a second record)
20153 and '20153' ... (for a third record)
...

Затем я добавляю индекс 1 в столбец'a' и индекс 2 в столбце'b'.

Вопрос в том, будет ли запрос выполняться одинаково быстро при выполнении в отношении столбца'a' как на колонке'b' (например.join запрос с другой таблицей на основе столбца'a' или на основе столбца'b' или жеWHERE пункт на любой из столбцов)?

Также - будет использовать индекс на 'varchar'column - использовать больше ЦП, чем использовать индекс для столбца' number '?

Благодарю.

 Thilo01 нояб. 2017 г., 14:44
Там не будет существенной разницы в производительности. Но если вы в настоящее время храните числа как varchar, это кажется очень странным дизайнерским решением.
 Joe01 нояб. 2017 г., 14:29
Я собираюсь перепроектировать базу данных (в настоящее время проверяю) - так что нет разницы в производительности? Как насчет использования ресурсов?
 Thilo01 нояб. 2017 г., 14:38
Храните числа как числа (до тех пор, пока они остаются в пределах поддержки и точности). Все остальное глупо.
 Thilo01 нояб. 2017 г., 14:24
Я не думаю, что это реальная проблема. Оба будут работать примерно одинаково. Выберите тип данных, который имеет смысл для данных (в частности, если вам нужно отсортировать, сравнить и использовать диапазоны).
 Joe01 нояб. 2017 г., 14:42
Я согласен с этим. Однако - я не проектировал базу данных со многими таблицами, но я участвую в редизайне, как я вижу, необходимо. Теперь, если я решу изменить дизайн с Varchar на Number - может потребоваться много работы для внесения изменений во все вовлеченные приложения. Но если разница очень очень мала - возможно, это усилие не стоит того ..

Ответы на вопрос(1)

[TL; DR] Используйте даты для хранения дат, цифры для хранения чисел и строки для хранения строк.

Как насчет использования ресурсов?

Oracle хранитNUMBER тип данных 1 байт на 2 цифры.

Oracle хранитCHAR Тип данных, как 1 байт на символ ASCII (UTF-8 и другие кодировки могут занять больше для символов в расширенных наборах), и строка справа будет вставлена ​​с пробелами, так что все строки имеют одинаковую длину.

Oracle хранитVARCHAR2 тип данных в виде 1 байта на символ ASCII плюс небольшие издержки (1 или 2 байта) для длины строки.

Oracle хранитDATE тип данных как7 байт (2 для года и 1 для каждого месяца, дня, часа, минуты, секунды).

На основеваш предыдущий вопрос Вы, кажется, хранитеyear а такжеquarter и при условии, что у вас всегда будут 4-значные годы и 1-значные кварталы, тогда:

NUMBER(5,0) займет 3 байта;CHAR(5 CHARACTER) займет 5 байтов;VARCHAR2(5 CHARACTER) займет 6 байтов; а такжеDATE займет 7 байтов.

Так что только учитывая памятьNUMBER(5,0) будет самым эффективным.

тем не мение

Как только вы начнете выполнять арифметику для года / квартала, хранящегося в виде чисел / строк, вы столкнетесь с проблемами производительности:

Например, получение следующего квартала:

Еслиquarter этоNUMBER Тип данных, то вы можете использовать:CASE WHEN MOD(quarter,10) = 4 THEN quarter + 7 ELSE quarter + 1 END но это не работает, когда вы хотите добавить 5 кварталов или начать вычитать кварталы, и тогда логика становится намного более сложной.Еслиquarter этоCHAR тип данных, то вы можете преобразовать его в число или дату и использовать любой из этих методов (манипулирование строками вряд ли будет эффективным).Еслиquarter этоDATE тогда вам просто нужно использоватьADD_MONTHS( quarter, 3 ).

DATE метод самодокументируется и уже существует, тогда какNUMBER метод просто станет пользовательской функцией для вашего приближенияQUARTER тип данных, и как только вы реализуете все функции сравнения и манипуляции, которые вам нужны, вы сможете эффективно переписатьDATE Тип данных как UDT для кварталов, и эти функции будут менее производительными, чем оптимизированные функции даты.

Не используйте неподходящие типы данных - просто сохраняйте даты как даты; числа как числа; и строки в виде строки.

Ваш ответ на вопрос