Одно дело — разовая заливка 5тб данных, другое — штатная работа.
В любом случае — если такое происходит в штатном режиме — то это не ACID. Вероятно, такое допустимо в больших системах, при этом не связанных с деньгами или другими критичными данными, вроде комментариев фейсбука.
PS:
под bulk insert я понял почему-то INSERT INTO… VALUES (...), (...)
> Индекс не поможет, если конструкция WHERE содержит условия поиска для двух таблиц;
Неправда. Перед выполнением запроса с INNER JOIN оптимизатор выполняет условия так, как ему удобно будет, а не так, как вы их записали в запросе (часть в ON, часть в WHERE). Потому — правильные составные индексы вполне себе будут использованы.
Я повторю в третий раз: я не спорю, что дамп получится кривой, я лишь говорю, что
> ну уж 65535 десятичных цифр — нам точно хватит
некорректно в принципе, даже в ироничной статье. В особенности после «Ведь все знают что bigint не ограничивается лишь 20 знаками. Как вы не знали? ну что ж это тоже легко доказать.»
Это не доказательство, а введение в заблуждение читателя (который не знает синтаксиса).
Я повторю ещё раз — вы как минимум вводите в заблуждение читателей, как максимум — заблуждаетесь сами, считая, что число 65535 имеет хоть какое-то влияние на хранимые данные.
Я не совсем понимаю, о чём вы говорите. Цифра в скобках (65535) вообще к диапазону хранимых значений никакого отношения не имеет. От того, что вы укажете там 1 или 42 — данные не изменятся абсолютно никак.
Вероятно в SQL Server встроена мощная система телепатии, чтобы отличить, что есть что в дате 2013-01-02
А если серьёзно — в скобках указано имя формата, которое указывается явно с помощью msdn.microsoft.com/en-us/library/ms189491.aspx
Но вообще, да, мой изначальный коммент становится некорректным — такой формат есть (хоть он и дикий)
ps: а, у автора был datetime, который тут не перечислен
В любом случае — если такое происходит в штатном режиме — то это не ACID. Вероятно, такое допустимо в больших системах, при этом не связанных с деньгами или другими критичными данными, вроде комментариев фейсбука.
PS:
под bulk insert я понял почему-то INSERT INTO… VALUES (...), (...)
Неправда. Перед выполнением запроса с INNER JOIN оптимизатор выполняет условия так, как ему удобно будет, а не так, как вы их записали в запросе (часть в ON, часть в WHERE). Потому — правильные составные индексы вполне себе будут использованы.
Т.е. субд может вернуть неактуальный результат?
Естественно. Вы выбрали половину записей таблицы. Зачем использовать индекс, если вам нужно так много записей.
S."somedatetime" BETWEEN '2012-26-11 11:30:00' AND '2012-31-12 11:32:00';В порядке месяца и дня в датах ошибки точно нет?
Почитать: www.regular-expressions.info/possessive.html
Я повторю в третий раз: я не спорю, что дамп получится кривой, я лишь говорю, что
> ну уж 65535 десятичных цифр — нам точно хватит
некорректно в принципе, даже в ироничной статье. В особенности после «Ведь все знают что bigint не ограничивается лишь 20 знаками. Как вы не знали? ну что ж это тоже легко доказать.»
Это не доказательство, а введение в заблуждение читателя (который не знает синтаксиса).
dev.mysql.com/doc/refman/5.5/en/numeric-type-attributes.html
> что ж выясним сколько знаков у нас есть
+
> ну уж 65535 десятичных цифр — нам точно хватит
Число знаков, которые позволяет сохранить тип определяется сугубо названием типа, а не числом в скобочках.
Про остальные примеры я не говорю, я с самого начала и до сих пор говорю о вашей единственной некорректной фразе.
Совсем не так. Знаковый bigint хранит значения от -9223372036854775808 до 9223372036854775807, т.е. 19 знаков. Что немного меньше, чем 65535,