Для работы проектов iXBT.com нужны файлы cookie и сервисы аналитики.
Продолжая посещать сайты проектов вы соглашаетесь с нашей
Политикой в отношении файлов cookie
Мне глубоко пофигу, чем они там занимаются — хоть под грибами камлают, хоть нейросетки учат.
Был бы там ИИ — результатом был бы не найденный АА вариант, а набор функций, описывающий зависимость свойств материала от его параметров, структуры и т.д. И дальше по этому набору был бы рассчитан нужный материал исходя из требуемых свойств, стоимости производства и прочих параметров.
Но этого всего нет, есть простой ассоциативный автомат. До ИИ тут, как до луны в известной позе.
ИИ из таблицы умножения вывел бы саму операцию умножения, возведения в степень, излечения корней. (Как и поступал ранее естественный интеллект).
АА из таблицы умножения будет искать целевое значение к ранее неизвестному входному значению, не более.
Где-то это применимо и имеет смысл, но 90% того, что сейчас происходит с ИИ — выбегалловщина как она есть.
Не имея теории, на базе которой можно рассчитать нужный материал, делаем «таблицу умножения» для ассоциативного автомата и пытаемся им закрыть пробелы в этой таблице. Блеск…
Это проблемы соевых. Для людей с мозгом работа со всякими вариантами *TeX проблем не составляет, более того — все знакомые техписы работают именно в нем. Да и автоматизированное документирование в нем делается очень легко.
Rollback — это все-таки нештатная операция, и тут уже зависит от проектирования приложения — она в штатном режиме происходит крайне редко. Отсутсвие point-in-time recovery для нагруженной системы — мягко скажем, не подарок. Как отсутствие аналога ODCI (в особенности параллельных операций). Слишком много гемора с этой «грешной» субд, пришлось отказаться.
Тут даже думать не надо было — достаточно было спионерить у оракла его архитектуру с undo (которая даже в несчастном mysql есть). Мало того, что архитектура с рожденья убогая, так еще и прочих веселостей много: update — дорогая ресурсно операция (у оракла — это rollback, т.е. нештатная операция при нормально спроектированном приложении), посмотреть, что залочила транзакция — только сканом всей базы (локи хранятся в самих записях), FK на секционированную таблицу сделать нельзя (ибо убого до нельзя)… Список большой.
Проще для средних нагрузок взять firebird, а для серьезного — брать mysql и делать свой слой кэширования и управления нагрузкой. Или «оракл босил, а мы подняли» — быстрее всего и эффективней.
“Приватный ключ генерируется чипом карты и хранится на карте.” — при утере карты и использовании другой из комплекта каким образом восстанавливается закрытый ключ?
Он на несколько голов выше рекламируемого хлама, и не под макитовские АКБ
Был бы там ИИ — результатом был бы не найденный АА вариант, а набор функций, описывающий зависимость свойств материала от его параметров, структуры и т.д. И дальше по этому набору был бы рассчитан нужный материал исходя из требуемых свойств, стоимости производства и прочих параметров.
Но этого всего нет, есть простой ассоциативный автомат. До ИИ тут, как до луны в известной позе.
ИИ из таблицы умножения вывел бы саму операцию умножения, возведения в степень, излечения корней. (Как и поступал ранее естественный интеллект).
АА из таблицы умножения будет искать целевое значение к ранее неизвестному входному значению, не более.
Где-то это применимо и имеет смысл, но 90% того, что сейчас происходит с ИИ — выбегалловщина как она есть.
Проще для средних нагрузок взять firebird, а для серьезного — брать mysql и делать свой слой кэширования и управления нагрузкой. Или «оракл босил, а мы подняли» — быстрее всего и эффективней.
— Тут план запроса 8 минут строится!
— Это by design
— А что она тормозит на ровном месте?
— Это autovacuum, так надо!
© техподдержка этой субд