Время удержания в базе данных: STRING vs TIMESTAMP

0

У меня есть база данных, в которой каждая запись является бизнесом, некоторые из них - время открытия и закрытия. Первоначально, чтобы поддерживать несколько открытий и закрытий в один день, я собирался сохранить его как строку, например: '09: 00-15: 00,17: 00-22: 00 ', а затем разделить ее и преобразовать в TIMESTAMPS серверная сторона. Теперь я понимаю, что "плохая форма" хранит времена как строки. Но для решения требуется вторая таблица.

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

Теги:
timestamp
database-design

3 ответа

1
Лучший ответ

Здесь есть три отдельных вопроса. Один из них заключается в том, лучше ли комбинировать два элементарных элемента данных в списке и хранить список в одном месте или хранить элементарные элементы отдельно и хранить их в двух отдельных местах. Для этих целей я рассматриваю пересечение одной строки и одного столбца как одно место.

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

Третья проблема заключается в том, лучше ли хранить точки во времени в виде строк или использовать тип данных временной метки СУБД.

Для первого выпуска лучше хранить отдельные элементарные элементы в отдельных местах. В этом случае в двух отдельных строках одной таблицы.

Для второй проблемы лучше описать временной интервал как две временные метки рядом друг с другом, чем объединить их в интервал для систем СУБД, которые я использовал. Но существуют системы СУБД, которые имеют тип данных временного интервала, который отличается от типа данных метки времени. Ваш пробег может отличаться.

Для третьей проблемы лучше использовать тип данных временной метки СУБД для описания момента времени, чем символьная строка. Различные продукты СУБД имеют разные возможности для хранения времени без какой-либо связанной с ним даты, и в этом случае вы можете использовать это. Это зависит от того, как вы будете искать данные. Если вам захочется найти все строки, содержащие временной диапазон от 9:00 до 15:00, независимо от даты, вы захотите воспользоваться этим. Если вы захотите найти все строки, содержащие 9:00 - 15:00, в любой вторник, я предлагаю вам изучить методы хранения данных.

Зачем?

Для первых двух ответов это связано с нормализацией, индексированием, поисковыми стратегиями и оптимизацией запросов. Эти концепции связаны друг с другом, и каждый из них поможет вам понять другие три.

Для третьего ответа это связано с использованием мощности СУБД для выполнения детальной работы для вас. Любая хорошая СУБД будет иметь инструменты для вычитания временных меток, чтобы получить временной интервал, и для правильной установки временных меток. Получение СУБД для выполнения этой работы позволит вам сэкономить много работы в вашем прикладном программировании и, как правило, использовать меньше компьютерных ресурсов на производстве.

Сказав это, я не знаю mySQL, поэтому я не знаю, насколько это хорошо для обработки дат или оптимизации запросов.

Поделиться
  • 0
    Спасибо. В конце концов, я думаю, что все сводится к тому, что в моей нынешней ситуации строковое решение будет более быстрым и простым, не затрагивая конечного пользователя, я сейчас мало занимаюсь манипуляциями со временем и большим количеством кодирования. Вы говорите, что это избавит меня от уже написано. Но я вижу, как с будущими обновлениями это может представлять проблему. Я новичок в продвинутой обработке баз данных и тому подобное, и обязательно изучу темы, которые вы перечислили. Большое спасибо за решение моего вопроса о том, почему, а не как.
0

Здесь есть три отдельных вопроса. Один из них заключается в том, лучше ли комбинировать два элементарных элемента данных в списке и хранить список в одном месте или хранить элементарные элементы отдельно и хранить их в двух отдельных местах. Для этих целей я рассматриваю пересечение одной строки и одного столбца как одно место.

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

Третья проблема заключается в том, лучше ли хранить даты в виде строк или использовать тип данных временной метки СУБД.

Для первого выпуска лучше хранить отдельные элементарные элементы в отдельных местах. В этом случае в двух отдельных строках одной таблицы.

Для второй проблемы лучше описать временной интервал как две временные метки рядом друг с другом, чем объединить их в интервал для систем СУБД, которые я использовал. Но существуют системы СУБД, которые имеют тип данных временного интервала, который отличается от типа данных метки времени. Вы можете варьироваться.

Для третьей проблемы лучше использовать тип данных временной метки СУБД для описания момента времени, чем символьная строка. Различные продукты СУБД имеют разные возможности для хранения времени без какой-либо связанной с ним даты, и в этом случае вы можете использовать это. Это зависит от того, как вы будете искать данные. Если вам захочется найти все строки, содержащие временной диапазон от 9:00 до 15:00, независимо от даты, вы захотите воспользоваться этим. Если вы захотите найти все строки, содержащие 9:00 - 15:00, в любой вторник, я предлагаю вам изучить методы хранения данных.

Почему я отвечаю на эти ответы?

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

Для третьего ответа это связано с использованием мощности СУБД для выполнения детальной работы для вас. Любая хорошая СУБД будет иметь инструменты для вычитания временных меток, чтобы получить временной интервал, и для правильной установки временных меток. Получение СУБД для выполнения этой работы позволит вам сэкономить много работы в вашем прикладном программировании и, как правило, использовать меньше компьютерных ресурсов на производстве.

Поделиться
0

К '09:00-15:00,17:00-22:00', вы имеете в виду, что он открыт в течение двух периодов времени? Затем 2 строки в одной таблице. Если время открытия меняется в зависимости от дня недели, то другой столбец указывает это. Если вы хотите провести отпуск, еще один столбец.

Но... Что вы будете делать с данными?...

Если вы собираетесь писать SQL для использования времени, то то, что я описал, может работать лучше всего.

Если обработка будет в вашем коде приложения, тогда файл CSV, который вы загружаете каждый раз, каждый раз анализируете и т.д., Может быть лучшим.

Или вы можете поместить этот CSV файл в таблицу как одну большую строку. (Тем не менее, это не сильно отличается от наличия файла.)

Поделиться
  • 0
    Да, я имею в виду, что это будут открытые периоды времени в один день. Нынешняя структура, которую я придумал, в основном соответствует описанной вами. Но в моей старой системе было два столбца для каждого дня недели значения TIMESTAMP. Но это не поддерживает несколько раз в течение одного дня. Вместо этого у меня был бы один столбец для каждого дня недели, который был бы строками. Что касается того, что я делаю с этими данными. Он обрабатывается на сервере для отображения пользователю, ищущему предприятия. Он также будет использоваться для определения того, открыт ли бизнес. (У меня уже есть эти функции)
  • 0
    Вы можете использовать тип данных TIME вместо TIMESTAMP .

Ещё вопросы

Сообщество Overcoder
Наверх
Меню