|
Задавайте вопросы, мы ответим
Вы не зашли.
Приветствую форумчан,
Я новичок в MySql, поэтому мой вопрос может показаться кому то легким (а может и нет).
Проектирую базу данных, и в одном столбце у меня будут значения от 0 до (вероятно) 100 000 000 000 (сто миллиардов).
Казалось бы с типом данных для столбца нет вопросов, это должен быть BIGINT.
Но проблема в том, что значений больше 4294967295 (INT (unsigned)) будет не больше 10-15 (это точно).
В придачу столбец будет индексированным потому что по его значениям будут выводиться (и сортироваться) страницы на сайте.
В самом столбце в перспективе будет от нескольких миллионов, до нескольких сотен миллионов значений. Но значений больше 4294967295 (как и говорил выше) не более 15.
Соответственно дилемма: Если сделать поле BIGINT, то и размер поля и размер индекса в базе данных будет в 2 раза больше чем INT, что рано или поздно (когда база разрастется) скажется на скорости выполнения запроса.
Если сделать поле INT, то вероятно для этих 10 -15 значений (которые больше 4294967295) придется создавать отдельную таблицу, и при запросах обращаться к обоим каждый раз, при этом еще приводить их к одному типу данных. А это в свою очередь рано или поздно также скажется на производительности (или нет?).
Собственно вопрос: как мне поступить в этом случае?
Сделать одну таблицу со столбцом в BIGINT?
Сделать две таблицы, одну со столбцом BIGINT и одну INT, обращаясь сразу к обеим?
Или еще какой вариант?
Надеюсь на помощь профессионалов.
Неактивен
Нельзя ли исключить BIGINT вообще? 10-15 значений выглядит странно. Еще, возможно, вы беспокоитесь о производительности слишком рано, пока еще не все понятно о том, какая будет база.
Всегда можно сделать какой-нибудь переоптимизированный вариант, например вместо больших чисел хранить взятый с обратным знаком id из второй таблицы. Таким образом, если id отрицательный, делаете отдельный запрос (из приложения) и получаете bigint - это не займет времени.
Неактивен
Строк точно будет до нескольких сотен миллионов (минимум несколько десятков), и из них только 10-15 значений больше 4294967295.
Ваш вариант я и имел ввиду для создания второй таблицы. Можно как вы предложили присвоить отрицательное значение и если оно, то искать во второй.
Я думал всем значениям больше 4294967295, присваивать именно 4294967295 (вероятность совпадения с этим числом очень мала), и если это число, то искать во второй (уже с реальными данными).
Но т.к. я новичок в MySql, у меня есть сомнения (просто я не уверен), что это может замедлить (в перспективе) эффективность запроса.
Ведь на самом деле в каждую проверку придется закладывать условие.
В придачу по первой таблице (где инт) невозможно будет отсортировать эти фиктивные (которые больше 4294967295, и которым будут присвоены фиктивные значения) значения, а значит будет еще процедура для сортировки уже реальных значений, да и еще вместе с остальными, т.к. к примеру нужно будет вывести 100 самых больших значений и из них 10 будет из второй таблицы (где бигинт).
В общем я не знаю как это может отразиться на производительности в будущем.
Неактивен
Проверку в запрос закладывать не нужно. Делаете запрос, как будто все в порядке. Потом, если число оказалось, скажем, 4294967295 делаете повторный запрос на получение конкретного числа из второй таблицы. Это придется делать для всех запросов с этим полем. Включение в запрос условия и JOIN убьет производительность и такая оптимизация потеряет смысл.
Неактивен
Большое спасибо.
А повторный запрос лучше делать не отключаясь от базы данных (т.е. в условии основного запроса) или получив результат, из пхп делать повторный запрос (повторно подключаясь)?
Неактивен
Делать отдельный запрос. Если привяжете к основному, то производительность станет хуже, чем без оптимизации.
Второй запрос из php не означает повторного подключения к базе данных. Все же лучше не занимайтесь преждевременной оптимизацией и начните с работающего приложения с bigint, а потом, если потребуется, оптимизируйте.
Неактивен
