числовой (38,0) как столбец первичного ключа; хороший, плохо, кто заботится?
Я, честно говоря, не смог составить рабочий относительный формат для strtotime () , который был бы элегантным однострочником, о котором мы все мечтаем, поэтому я написал петля бедняка:
/**
* @param int $month
* @param int $day
* @param int $reference Unix time, defaults to today
* @return int Unix time
*/
function nextOcurrence($month, $day, $reference = null)
{
if ($reference === null) {
$reference = mktime(0, 0, 0);
}
$year = date('Y', $reference);
while (!checkdate($month, $day, $year) || ($date = mktime(0, 0, 0, $month, $day, $year)) <= $reference){
$year++;
}
return $date;
}
Основные моменты:
- «Сегодня» не является жестко запрограммированным, чтобы облегчить тестирование.
- Он принимает во внимание високосные годы, но не Пап, играющих с календарем .
- Он использует метки времени Unix, поэтому он не может обрабатывать даты до 1970 года в 32-битном PHP.
- Даты трудны, так что, вероятно, неправильно.
Демо .
4 ответа
Ну, Вы тратите больше данных для хранения чисел, которых Вы никогда не будете действительно достигать.
bigint подходит 9,223,372,036,854,775,807 в 8 байтах
интервал подходит 2,147,483,647 в 4 байтах
ЧИСЛОВОЕ (38,0) собирается взять, если я делаю математику правильно, 17 байтов.
Не огромная разница, но: меньшие типы данных = больше строк в памяти (или меньше страниц для того же # строк) = меньше диска ввод-вывод, чтобы сделать поиски (или индексированная или страница данных ищет). Идет то же для репликации, страниц журнала, и т.д.
Для SQL Server: INT является стандартом IEEE и так легче для ЦП выдержать сравнение, таким образом, Вы получаете небольшое увеличение производительности при помощи INT по сравнению с Числовым (который является форматом упакованного десятичного числа). (Отметьте в Oracle, если текущая версия соответствует более старым версиям, я рос на, ВСЕ типы данных упаковываются так, INT внутри является в значительной степени тем же самым как ЧИСЛОВЫМ (x, 0), таким образом, нет никакого различия в производительности),
Так, в главной схеме вещей - если Вы имеете много диска, RAM, и экономите ввод-вывод, используют любой тип данных, который Вы хотите. Если Вы хотите получить немного больше производительности, немного более консервативны.
Иначе в этой точке, я оставил бы его как есть. Никакая потребность изменить вещи.
Запрещая соображения устройства хранения данных и некоторый начальный беспорядок от будущего DBAs, я не вижу оснований, почему ЧИСЛОВОЙ (38,0) была бы плохая идея. Вы допускаете до 9,99 x 10^38 записи в Вашей таблице, которой Вы никогда не будете, конечно, достигать. Мое быстрое рытье в это не подняло явной причины не использовать его. Я подозреваю, что Вашей единственной потенциальной проблемой будет пространство памяти, использованное этим, но видящий как, как пространство памяти является настолько дешевым, который не должен быть проблемой.
Я видел это достаточное количество времен в базах данных Oracle, так как это - довольно большое значение по умолчанию, что Вы не должны думать о том, когда Вы составляете таблицу, подобную использованию INT или BIGINT по умолчанию в SQL Server.
Вы были бы более обеспеченным использованием GUID.В самом деле. Нормальная причина не использовать каждый - то, что целое число работает лучше. Но GUID меньше, чем числовой (38) и обладает дополнительным преимуществом создания его немного легче сделать, вещь как разъединенные пользователи, которым позволяют, создает и синхронизирует новые записи.
Это является чрезмерно большим, потому что Вы никогда не собираетесь иметь это много строк. Больший размер приведет к большему пространству памяти. Это не грандиозное предприятие сам по себе, но будет также означать больше чтения с диска получать данные из таблицы или индекса. Это будет означать, что меньше строк впишется в память на сервере базы данных.
Я не думаю, что это повредилось достаточно, чтобы быть побеспокоенным, фиксируя.