В результате 3 клиента, которые физически находятся на одном компьютере, заполняют поле с типом timestamp разными значениями ... Напротив, для колонки с типом timestamptz все в порядке.
Есть подвох. Дело в том, что нигде в БД не хранятся сведения о том, какая собственно зона на сервере в момент вставки записи. То есть поле типа timestampz даёт правильное относительное расположение/смещение меток друг от друга, но никоим образом не указывает на абсолютный момент времени для хранящегося значения. Нет, пока всё остаётся в рамках одного сервера, и его не перестраивают, всё в порядке. А если надо перенастроить зону? А если надо передать дамп для развёртывания в другой зоне?
Так что как по мне, то хранение timestamp плюс зоны времени клиента в дополнительном поле ещё надёжнее. Несмотря на бОльшее потребление пространства (аж цельный байт на запись, да ещё и с учётом страничности хранения) и повышенную сложность обработки.
Что-то прям ерунда какая-то с иерархиями. Причём дважды.
Во-первых - а где собственно иерархия-то? если не считать наименований полей, то я в упор не вижу никакого отличия между иерархическими и обычными атрибутами.
Во-вторых, заполнение. SQL-запрос на наполнение куба как-то намякивает, что в таблице TimeDim для каждой записи хранятся и дата, и месяц, и год, и все по отдельности, в разных полях одной записи... нормализация тихо плачет в уголочке.
обнаружены два континентальных сгустка из необычного материала: один под Африканским континентом, другой — под Тихим океаном. Каждый из них в два раза больше Луны и, вероятно, состоит из элементов, отличающихся по пропорциям от окружающей его мантии
Диаметр Луны - 3474 км. Земли - 12742 км. Два шарика диаметром в две Луны в контурах Земли тупо не поместятся. Даже если не учитывать, что после запихивания внутрь таких двух шариков надо, чтобы осталось место на ядро (диаметр которого порядка 7000 км).
Ну или - толщина мантии порядка 2900 км. Как в ней опять же может поместиться шарик размером в две Луны?
А теперь точно и подробно, что именно имеется в виду. Хранимая таблица - это несортированная и неупорядоченная куча, причём так дело обстоит в обеих СБД. Что именно упорядочено? где? как?
прямые ссылки между узлами, позволяющие выбирать поддеревья без лукапа
Да ладно! Вот так прям в каждой записи каждой таблицы и лежит полный путь текущей записи, перечисляющий узлы во всех таблицах аж до самого корня дерева связей? Вот что-то не верится.
НУ вообще-то после машинного перевода надо было бы просмотреть результат и отрихтовать его. "Incompatible Change" -> "Инсопостимое изменение" - бррр...
Ну и, уж коли перевод, то надо было об этом явно сказать. И ссылку дать на оригинал.
Прочитал всё... но так и не понял, что вообще заставило использовать подход иерархической БД (ИБД), когда снизу - реляционная СУБД, на которой ИБД реализуется легко и непринуждённо, считай нативно, достаточно всего лишь некоторого самоограничения. Ну и терминология - что бы не использовать стандартную и уже устоявшуюся?
Отношение М:М между двумя сущностями легко реализуется через нижний узел (абcтрактную сущность).
Ну то есть просто превращаем иерархическую БД в реляционную, что ли? Ну или не превращаем, да, маловато будет, но используем технологию из реляционной БД. Просто с точки зрения иерархической БД такая промежуточная сущность безусловно является самостоятельной сущностью, возможно, не имеющей атрибутов, тогда как в реляционной БД считать такую промежуточную таблицу сущностью никто не заставляет (хотя и не запрещает - и порой считают). Но это всего лишь вопрос терминологии. Или глубины анализа предметной области.
молекулы, связанные с жизнью, такие как гормоны и метаболиты (продукты метаболических реакций), действительно сложнее и требуют больше информации для сборки, чем молекулы, не связанные с жизнью, такие как углекислый газ.
Смешно. Коню понятно, что экскаватор сложнее лома. А вы попробуйте провести сравнение для молекул "на одном уровне", близких по молекулярной массе и количеству атомов.
А всего-то и надо было что, решить переопределённую систему из 4 линейных уравнений с 3 неизвестными - определить её совместность и, если да, найти решение.
Кстати, а программа предусматривает вариант совпадения прямых?
Только что провёл эксперимент. Есть у меня в резерве Samsung Galaxy Note 3, со всеми родными прибамбасами, который я когда-то пользовал, и Samsung Galaxy J4, которым пользуюсь сейчас, опять же все родные аксессуары в наличии.
Пробовал зарядку обоих с каждым из кабелей и разными источниками питания - два родных блока, два "левых", USB-разъём на материнке и активный USB-хаб.
Так вот - Samsung Galaxy Note 3 заряжается нормально от любого из кабелей и любого из блоков, тогда как Samsung Galaxy J4 при использовании своего кабеля заряжается нормально, а с кабелем от енота-3 показывает "медленный заряд" вне зависимости от того, какой блок используется.
Как-то оно слегка не вписывается в идею статьи... ну или "не кабелем единым".
Настоятельно рекомендую попробовать... мне как-то они помогли даже в задаче, далёкой от работы с картой, но требовавшей R-tree index для оптимизации - и здОрово, надо сказать, помогло.
Только учитывайте, что далеко не каждая spatial-функция умеет использовать такой индекс. И что самое противное, нет нигде вменяемого полного списка функций, которые используют (или не используют) такой индекс, всё приходится определять опытным путём. По счастью, в наборе геофункций есть сплошь и рядом полу-дубликаты, как правило, одну и ту же проверку можно выполнить несколькими способами.
Более того, в БД пихали XYZ на единичной сфере, просто синусы-косинусы сферических координат. А средний радиус земли уже учитывали в пред- и пост-обработке запросов.
Много ли на "чистом" sql можно написать такого что нельзя сделать через orm?
Ой, много! Достаточно регулярны вопросы на форумах типа "как вот это реализовать в моём ОРМ" - и изрядная их часть решается исключительно использованием RAW SQL..
То есть если в течение месяца без сна и отдыха штамповать чеки по штуке каждые 10-11 секунд - как раз в этот аппаратный предел и впишешься. Практически - нереально.
Почему с переходом на "онлайн кассы" не решили этот регулярный гемморой с переполнением
А это чисто случайно не косячок ли определённой линейки, конкретной модели или даже определённой версии прошивки? А то есть у меня под наблюдением и поддержкой на работе несколько штук - и ни на одном такой штукенции как переполнение нет в принципе.
Есть подвох. Дело в том, что нигде в БД не хранятся сведения о том, какая собственно зона на сервере в момент вставки записи. То есть поле типа timestampz даёт правильное относительное расположение/смещение меток друг от друга, но никоим образом не указывает на абсолютный момент времени для хранящегося значения. Нет, пока всё остаётся в рамках одного сервера, и его не перестраивают, всё в порядке. А если надо перенастроить зону? А если надо передать дамп для развёртывания в другой зоне?
Так что как по мне, то хранение timestamp плюс зоны времени клиента в дополнительном поле ещё надёжнее. Несмотря на бОльшее потребление пространства (аж цельный байт на запись, да ещё и с учётом страничности хранения) и повышенную сложность обработки.
Что-то прям ерунда какая-то с иерархиями. Причём дважды.
Во-первых - а где собственно иерархия-то? если не считать наименований полей, то я в упор не вижу никакого отличия между иерархическими и обычными атрибутами.
Во-вторых, заполнение. SQL-запрос на наполнение куба как-то намякивает, что в таблице TimeDim для каждой записи хранятся и дата, и месяц, и год, и все по отдельности, в разных полях одной записи... нормализация тихо плачет в уголочке.
А точно терабайт? у меня хард больше...
Оформление - на двойку.
Приводимый в статье код должен быть как минимум выполняемым. Замените смарт-кавычки на правильные.
Не, а почему в код попало только одно тире из двух?
Я бы понял, будь написано "это значение параметра" - но "запрос"??
PS. Содержание даже не оцениваю - а то наговорю сейчас...
Диаметр Луны - 3474 км. Земли - 12742 км. Два шарика диаметром в две Луны в контурах Земли тупо не поместятся. Даже если не учитывать, что после запихивания внутрь таких двух шариков надо, чтобы осталось место на ядро (диаметр которого порядка 7000 км).
Ну или - толщина мантии порядка 2900 км. Как в ней опять же может поместиться шарик размером в две Луны?
Ну полное РенТВ...
А теперь точно и подробно, что именно имеется в виду. Хранимая таблица - это несортированная и неупорядоченная куча, причём так дело обстоит в обеих СБД. Что именно упорядочено? где? как?
Да ладно! Вот так прям в каждой записи каждой таблицы и лежит полный путь текущей записи, перечисляющий узлы во всех таблицах аж до самого корня дерева связей? Вот что-то не верится.
НУ вообще-то после машинного перевода надо было бы просмотреть результат и отрихтовать его. "Incompatible Change" -> "Инсопостимое изменение" - бррр...
Ну и, уж коли перевод, то надо было об этом явно сказать. И ссылку дать на оригинал.
А что есть такого в ИБД, что отсутствует в РСУБД? Я что-то навскидку и не нахожу... а, значит, ИБД - это РСУБД с дополнительными ограничениями.
Прочитал всё... но так и не понял, что вообще заставило использовать подход иерархической БД (ИБД), когда снизу - реляционная СУБД, на которой ИБД реализуется легко и непринуждённо, считай нативно, достаточно всего лишь некоторого самоограничения. Ну и терминология - что бы не использовать стандартную и уже устоявшуюся?
Ну то есть просто превращаем иерархическую БД в реляционную, что ли? Ну или не превращаем, да, маловато будет, но используем технологию из реляционной БД. Просто с точки зрения иерархической БД такая промежуточная сущность безусловно является самостоятельной сущностью, возможно, не имеющей атрибутов, тогда как в реляционной БД считать такую промежуточную таблицу сущностью никто не заставляет (хотя и не запрещает - и порой считают). Но это всего лишь вопрос терминологии. Или глубины анализа предметной области.
Смешно. Коню понятно, что экскаватор сложнее лома. А вы попробуйте провести сравнение для молекул "на одном уровне", близких по молекулярной массе и количеству атомов.
"завила"? или всё же "заявила"?
А всего-то и надо было что, решить переопределённую систему из 4 линейных уравнений с 3 неизвестными - определить её совместность и, если да, найти решение.
Кстати, а программа предусматривает вариант совпадения прямых?
Только что провёл эксперимент. Есть у меня в резерве Samsung Galaxy Note 3, со всеми родными прибамбасами, который я когда-то пользовал, и Samsung Galaxy J4, которым пользуюсь сейчас, опять же все родные аксессуары в наличии.
Пробовал зарядку обоих с каждым из кабелей и разными источниками питания - два родных блока, два "левых", USB-разъём на материнке и активный USB-хаб.
Так вот - Samsung Galaxy Note 3 заряжается нормально от любого из кабелей и любого из блоков, тогда как Samsung Galaxy J4 при использовании своего кабеля заряжается нормально, а с кабелем от енота-3 показывает "медленный заряд" вне зависимости от того, какой блок используется.
Как-то оно слегка не вписывается в идею статьи... ну или "не кабелем единым".
Настоятельно рекомендую попробовать... мне как-то они помогли даже в задаче, далёкой от работы с картой, но требовавшей R-tree index для оптимизации - и здОрово, надо сказать, помогло.
Только учитывайте, что далеко не каждая spatial-функция умеет использовать такой индекс. И что самое противное, нет нигде вменяемого полного списка функций, которые используют (или не используют) такой индекс, всё приходится определять опытным путём. По счастью, в наборе геофункций есть сплошь и рядом полу-дубликаты, как правило, одну и ту же проверку можно выполнить несколькими способами.
Гм... у геоданных есть параметр SRID вообще-то..
Чем рожать костыль, лучше было бы построить и использовать spatial index.
https://dev.mysql.com/doc/refman/5.7/en/using-spatial-indexes.html
Например, когда нужны два UNIQUE constraint на одной таблице.
Ой, много! Достаточно регулярны вопросы на форумах типа "как вот это реализовать в моём ОРМ" - и изрядная их часть решается исключительно использованием RAW SQL..
То есть если в течение месяца без сна и отдыха штамповать чеки по штуке каждые 10-11 секунд - как раз в этот аппаратный предел и впишешься. Практически - нереально.
А это чисто случайно не косячок ли определённой линейки, конкретной модели или даже определённой версии прошивки? А то есть у меня под наблюдением и поддержкой на работе несколько штук - и ни на одном такой штукенции как переполнение нет в принципе.