Целое число против строки в базе данных
Я удивлен, что никто не ответил на этот вопрос кодом!
Простой способ рассчитать время, как ответил @JoshBerke, можно закодировать следующим образом:
DateTime startTime = DateTime.Now;
for (int index = 0, count = lines.Count; index < count; index++) {
// Do the processing
...
// Calculate the time remaining:
TimeSpan timeRemaining = TimeSpan.FromTicks(DateTime.Now.Subtract(startTime).Ticks * (count - (index+1)) / (index+1));
// Display the progress to the user
...
}
Этот простой пример отлично подходит для простого расчета прогресса. Однако, для более сложной задачи есть много способов, чтобы этот расчет мог быть улучшен!
Например, когда вы загружаете большой файл, скорость загрузки может легко меняться. Чтобы вычислить наиболее точный «ETA», хорошим алгоритмом было бы только рассмотрение последних 10 секунд прогресса. Выполните ETACalculator.cs для реализации этого алгоритма!
ETACalculator.cs из Progression - библиотека с открытым исходным кодом, которую я написал. Он определяет очень простую в использовании структуру для всех видов «расчета прогресса». Это позволяет легко вставлять шаги, сообщающие о разных типах прогресса. Если вы обеспокоены восприятием производительности (как предложил @JoshBerke), это очень поможет вам.
15 ответов
В моей стране почтовые индексы также всегда состоят из 4 цифр. Но первая цифра может быть нулем.
Если вы храните «0700» как целое число, вы можете получить много проблем:
- Это может быть прочитано как восьмеричное значение
- Если оно читается правильно как десятичное значение, оно превращается в «700»
- Когда вы получаете значение «700», вы должны не забыть добавить ноль
- Если вы не добавите ноль, позже как вы узнаете, если "700" - это "0700", или кто-то неправильно набрал "7100"?
Технически, наши почтовые индексы на самом деле являются строками, даже если это всегда 4 цифры.
Вы можете хранить их как целые числа, чтобы сэкономить место. Но помните, что это простой трюк DB, и будьте осторожны с ведущими нулями.
Но как насчет сохранения количества файлов в торренте? Целое число или строка?
Это явно целое число.
Всегда важно понимать семантику данных, с которыми вы работаете. Позвольте мне объяснить это на примере.
Предположим, вы хотите сохранить PIN-код в своей базе данных. Чтобы ответить, какой тип данных вы должны использовать, вы должны сначала ответить, что на самом деле означает PIN-код ( Персональный идентификационный номер ).
-
Если это действительно число, как на самом деле указывает его имя, то я не вижу причин, почему его не следует представлять в виде целого числа.
Некоторые люди могут утверждать, что вы не можете различить 0001 и 01. Очевидно, они не считают ПИН-кодом число, и если они работают с такой семантикой, им следует использовать строку.
Примечание. Если длина ПИН-кода будет фиксированной, скажем, до 4 цифр, они все равно могут использовать целое число, поскольку любое число всегда будет заполняться начальными нулями и будет точно таким же (0001 будет таким же, как 01) - но это фиксированное ограничение длины типично для чисел, чтобы избежать неправильного ввода.
-
Если в семантике четко указано, что ПИН является числом, т. Е. Что ПИН 0001 в точности совпадает с ПИН 01, я бы использовал целочисленное представление.
Поэтому в вашем случае важно понимать почтовый индекс семантику. Эта семантика может варьироваться в разных странах (или даже меняться со временем), поэтому также важно, что вы хотите использовать. Чтобы охватить все виды почтовых индексов и даже возможные изменения, я бы рассмотрел возможность использования более абстрактного типа данных или просто строки (я считаю, что уже есть семантика, которая содержит больше символов, чем просто цифры).
Я бы не рекомендовал следовать упрощенным правилам, таким как правило об арифметических операциях над представлением данных. Если вы не хотите выполнять математические операции с данными сейчас, это не значит, что вы не захотите иногда в будущем.
У вас есть данные, и вы хотите их сохранить, как-то их представить - просто подумайте, с чем вы работаете.
Иногда «всегда» означает «на следующий месяц». Я бы не стал рассчитывать на то, что 4-значные коды не будут буквенно-цифровыми в течение срока моей ответственности.
Некоторые диалекты SQL поддерживают тип данных, например NUMBER (4). Это работает как строка символов, но алфавит от 0 до 9.
Важнейшим фактором, определяющим imho, является необходимость приложения выполнять числовые арифметические вычисления значений, если нет, то единственной причиной использования целых чисел является снижение требований к хранилищу (что может быть важно для производительности). в критически важном приложении - например, путем уменьшения ширины индекса таблицы для увеличения производительности индекса), но в остальном, как правило, это не важно ...
Если нет необходимости выполнять арифметику со значениями, тогда Строка самая лучшая.
Почтовые индексы - это строки. В некоторых комментариях эти строки могут состоять только из числовых цифр, но это не делает их целыми числами. И рано или поздно ваша потальная система иссякнет и решит начать использовать буквы. Если ваша база данных использует целые числа для поля почтового индекса, вы будете в глубокой задумчивости.
Итог - если вы не будете делать арифметику, это, вероятно, не совсем число.
Также полезно помнить, что не все почтовые индексы во всех странах являются только цифрами. То, что у вас сейчас нет адресов в Канаде, еще не значит, что у вас их не будет. Я всегда придерживался правила: если вы хотите выполнять математические вычисления, храните их в числовом виде, если это просто код (почтовые индексы, телефоны, SSN, номер участника и т. Д.), То я сохраняю его в виде строки. Чего вы хотите избежать, так это любого ненужного преобразования данных в другой формат каждый раз, когда вы вызываете его (например, код для добавления начальных нулей, если вы сохраняете почтовый индекс в виде числа или код для преобразования строки в число для вычислений). ). Это могут быть дорогостоящие операции, если вам нужно выполнять их многократно, особенно когда таблицы большие и в итоге вам нужно выполнить преобразование в предложении where. Гораздо лучше хранить данные так, как вам нужно.
Я не вижу проблем с сохранением почтового индекса в виде числа, даже если вы не собираетесь выполнять над ним математические операции.
В нашем корпоративном хранилище данных мы получаем данные из многих устаревших систем. В результате мы видим, что используется много мусорных данных.
Возьмем наш случай, когда у нас есть географический идентификатор, который представляет собой заполненное нулями 4-значное «числовое» значение. Это поле часто используется для объединения таблиц.
Я бы выбрал один из двух подходов: 1) объявить столбец как поле char длины 4 и добавить CONSTRAINT LIKE '[09] [09] [09] [09]' 2) определить его как числовую длину 4 и, если пользователи этого хотят, отформатируйте значение только при отображении.
Подход с цифрой 1 избавляет вас от необходимости постоянного форматирования, что не составляет особого труда, но если вы часто фильтруете и даже индексируете / объединяете столбец, я бы сказал, что у нас нет варианта №2.
Третья причина в том, что мой опыт заключается в том, что люди просто ленивы, когда дело доходит до добавления ограничений в базу данных, или они невежественны. Я думаю, что это больше лень, лично. Я считаю, что существующие ограничения в основном применяются как изменения в приложении, которое первоначально собирает данные, и эти изменения не применяются единообразно.
В результате наше хранилище данных в конечном итоге получает все виды вариаций, включая непоследовательное предварительное заполнение нулями или обоснование значения.
Когда вы определяете что-то как INTEGER, вы автоматически получаете более эффективное хранилище, особенно при индексации по столбцу, а также и редактирования, которое все понимают, и, скорее всего, будут последовательно применяться в унаследованных системах разработчиками баз данных с различными возможностями.
У меня нет проблем с вариантом № 1, за исключением использования поля в индексе и моей озабоченности подходом, когда вы принимаете поле как афа-число, люди склонны добавлять в него больше мусора.
Взять, к примеру, наш идентификатор сотрудника Peoplesoft. Кто-то решил добавить «X» перед «числом», заполненным нулями, состоящим из 6 символов, чтобы обозначить, что работник является подрядчиком. Это нарушает мою личную практику не объединять отдельные части информации в одно поле. Это вызвало всевозможные проблемы несоответствия в разных системах. Если бы это поле было числовым, никто бы не попытался это сделать.
Комментарии?
Я не использую числовой тип данных, если я не собираюсь выполнять математические расчеты с данными. Зачем рисковать поиском проблемы в будущем для чего-то, что вы «уверены», всегда будет числом, в которое кто-то решит вставить нечисловой символ.
Если вы не собираетесь заниматься математикой сделай это строкой.
Для почтового индекса я бы выбрал строку. По сути это не целое число. Это просто идентификатор чего-то, и это может быть также последовательность из четырех символов.
Что касается количества файлов внутри торрента, это должно быть целое число.
Почтовый индекс - это не число: это код или идентификатор. То же самое относится и к телефонным номерам.
Количество файлов в торренте является целым числом.
Не в последнюю очередь, в этом случае вы можете создать CHECK CONSTRAINT LIKE '[09][09][09][09]' для поддержания правильности данных на уровне базы данных.
Что касается почтовых индексов, это типичный британский почтовый индекс:
EC2R 6PK
В университете мой лектор по базам данных сказал мне кое-что, что застряло со мной и все еще имеет место 15+ лет спустя:
Если вы выполняете арифметику, сохраняйте ее как число. В противном случае это строка.
Честно говоря, я не думаю, что вы можете ошибиться с этим советом.
Очевидно, что вы не выполняете арифметику для почтовых индексов, поэтому они являются строками.
Это вопрос семантики. Вы пытаетесь выбрать подходящий тип данных для хранения, что может быть сложным вопросом. Лучшее практическое правило - хранить ваши данные в виде целых чисел, если вам нужно будет использовать данные как целое число.
Другими словами, поскольку вы никогда не будете использовать почтовый индекс в качестве числа, нет смысла хранить его как единое целое. Неважно, как выглядят данные , важно, что это за . Является ли почтовый индекс числом? Нет, это строка символов, состоящая из полностью цифровых символов. Поэтому почтовый индекс лучше всего хранить в виде строки.
Я всегда использую следующее правило:
Если вы планируете выполнять на нем математические вычисления (добавление / вычитание / и т. Д.), Сделайте его целочисленным или другим числовым типом данных.
Если вы не планируете выполнять какие-либо математические вычисления на поле, сохраните его в виде строки.
В случае почтовых индексов у вас никогда не должно быть времени, когда вам нужно добавить к почтовому индексу, или вычесть, или умножить два почтовых индекса вместе. Математические функции обычно не используются в почтовых индексах, потому что они используются в качестве идентификаторов, а не количеств. Поэтому вы должны хранить свой почтовый индекс в виде строкового типа
По моему мнению, для почтовых индексов вы должны использовать строки, потому что у вас могут быть почтовые индексы с нулями (09100), и если вы используете целые числа, это будет 9100: сортировка не проблема, потому что есть еще алфавитный заказ («09100» предшествует «09101»). Для хранения номеров файлов я бы ожидал целое число, поэтому у вас нет проблем с увеличением / уменьшением его номера. Таким образом, целое число против строки зависит от того, какое использование вы делаете!
Является ли '0000' почтовым индексом? Отличается ли он от «0»?
Если это всегда четырехзначное число, я бы всегда сохранял его как 4 цифры, и это указывало бы на сохранение его в виде строки.