Задать вопрос
Пользователь пока ничего не рассказал о себе

Достижения

Все достижения (1)

Наибольший вклад в теги

Все теги (28)

Лучшие ответы пользователя

Все ответы (52)
  • MSSQL and mysql в чем отличие?

    @Miron11
    Пишу sql 20 лет. Срок :)
    Не удалось выполнить действие "Создать" для следующего объекта: "Пользователь", "sa".
    ---
    И чем вас это обеспокоило? Пользователь sa уже создан, ошибка в данном случае вполне может быть проигнорирована.
    ---
    Есть наверное различные пакеты для трансляции MSSQL Server -> MySQL. запрос в Яндексе "migration from sql server to my sql" третьей линией привел сюда.
    По опыту, на поверхности, многое действительно поддается трансляции, но процедуры и функции, нет.
    Но чуть от поверхности, MySQL уступает в плане отладки и выявления ошибок. А проблемы с правами пользователей мало отличаются. Попытка создать пользователя, который уже есть приведет к той же ошибке и в MySQL.
    Есть конечно возможности отладить код создающий объекты, применяя "IF NOT EXIST" выражение. Профессионалы используют два подхода для кода создающего объекты.
    Подход №1 - фирменный подход специалистов, проверять существование объекта, прежде чем его создать.
    Людям свойственно это делать, чтобы обеспечить наименьшие трения с чтением и пониманием ошибок. В этом случае детальное чтение ошибок необходимо для выявления дефектов.
    Такой код удобен тем, что его можно повторять снова и снова, результат будет всегда один и тот же, а ошибки будут выданы только в случае дефекта, или записи будут чистыми.
    Подход №2 - обычно используют создатели по, которое пишет скрипт "создать такой-то объект", с оглядкой на профессионального пользователя, который ( как считают создатели по ) достаточно знаком и с синтаксисом, и с важностью тех или иных сообщений, и сможет прочитать "с листа" записи машины, и справиться с выдачей решения "все хорошо" или "что-то сломалось" благодаря накопленным знаниям.
    У меня сложилось впечатление, что Вы работаете с кодом, созданным в подходе №2. Возможно если Вы прибавите детали, и опишете что Вы делаете, отвечающим на вопрос будет проще справиться с ответом.
    Всего хорошего
    Ответ написан
    2 комментария
  • В каких случаях стоит предпочесть MS SQL Server другим БД?

    @Miron11
    Пишу sql 20 лет. Срок :)
    MySQL имеет значительно более слабая поддержка выполнения запросов
    Вплоть до 5.7 не имел процедур.
    Хотя структуры языка позволяющие создать процедуры у MySQL после этого появились, как такового языка программирования, выполнения логических операций, у MySQL не существовало. Возможно это изменилось. Но скорее нет.
    Таким образом называть MySQL полноценной СУБД нельзя.
    Если кого - то возможно не смущает создание кластеризованных индексов "по умолчанию", то для меня отсутствие подобных рычагов управления верстки цифровых записей неприемлемы.
    ----
    PosgreSQL база совершенно иного уровня, в плане академических требований, но вплоть до 9-й версии страдала от файл-объектной структуры записи, то есть каждая таблица или индекс это свой файл. Неизбежным результатом оказались провалы в аккуратности учета данных, когда от базы потребовались решения сверхзадач. Передача файловой системе ОС ответственности за аккуратность учета операций записи привели к потере самой базой доверия пользователя ( Uber ).
    Ситуация была выправлена в авральном порядке, и теперь у PostgreSQL все в полном порядке. Костяк команды разработчиков сумел быстро поправить ситуацию через несгибаемую волю и удивительный профессионализм ( как нам всем сейчас этого в России не хватает после того, как это было в избытке в советское время ).
    Поэтому с PostgreSQL на сегодня вопрос конечно не простой. Но и здесь, конечно, базе, которую поддерживают исключительными личными жертвами группа волевых и компетентных соратников, трудно тягаться с коллективом у которого есть цель, план развития, и видение изнутри всего многообразия цифровой индустрии.
    Ни у одной базы никогда не будет возможности похвастаться полноценной и постоянно улучшающейся поддержки очередей, встроенных каталогов интеграции данных, отдельная но хорошо отлаженная для совместной работы на сервере службы OLAP, и полноценного ядра обработки данных непосредственно в памяти резидента выполнимого ( Hecaton ). Плюс разнообразные форматы хранения данных, безупречная поддержка языков и кодирования символов, c SQL Server трудно состязаться. А возможность запросто вскрыть протокол общения и просмотреть запросы выполненные базой через profiler делают работу как разработчика, так и службы поддержки простой и легко поддающейся уму человека, у которого есть семья, дети, родители, и что - то в жизни, кроме работы.
    ----
    Я писал этот пост и уже тогда подумал, что MySQL и PostgreSQL не полный выбор из возможного списка конкурентов SQL Server на место СУБД. Меня, в свое время, заинтересовал Линтер. Раньше эта СУБД считалась русской, но в 2015-м - 17-м проскользнули данные о выкупе продукта зарубежными гражданами. Оставив темную историю с правами на продукт в стороне, по моим оценкам у базы есть все необходимые качества для обслуживания цифрового предприятия.
    Возможно там есть ограничения по количеству потоков, объему хранимых данных. Это наверное надо проверить с поставщиком.
    Поиск и оценку русских продуктов СУБД я веду непрерывно, и буду благодарен за любые подсказки и указатели.
    Ответ написан
    1 комментарий
  • Книги, курсы по архитектуре приложений?

    @Miron11
    Пишу sql 20 лет. Срок :)
    Один мудрый индийский рекрутер поделился со мной аббревиатурой TOGAF, а всё остальное я нашел сам.
    Надеюсь Вам тоже поможет.
    Не самое важное, на мой скромный взгляд вопрос тянет на уровень сложности средний.
    Ответ написан
    1 комментарий
  • Какая из баз данных лучше всего подходит для хранения большого словаря?

    @Miron11
    Пишу sql 20 лет. Срок :)
    А Вы не пробовали добавить индекс на поле из 4-х байтов?
    На MySQL индексы работают вполне приемлемо, главное, чтобы это был первый индекс созданный на таблице, тогда InnoDB ( default ) движок по умолчанию создаст кластеризованный индекс.
    Вот синтаксис: https://dev.mysql.com/doc/refman/8.0/en/create-ind...
    обратите внимание на варианты UNIQUE, это поможет подтвердить, что ключ каждого текстового поля действительно уникальный.
    Потом, во время запроса, надо будет аккуратно проверить синтаксис, чтобы подтвердить что запрос создан так, что индекс будет использован - тип данных в WHERE должен соответствовать, и что запрос действительно его использует ( по моему в MySQL это опция EXPLAIN ).
    Если все сделано верно, то скорость выполнения запроса с миллиардом записей должна быть вполне приемлема.
    Осталось проверить некоторые детали. Из вопроса не очень понятно, если база многопользовательская, или обслуживает пользователя работающего на этой же машине, есть ли одновременный доступ нескольких пользователей, иными словами доп информация по масштабу использования базы может помочь. И хотя SQLite намекает на чисто локальный характер записей, это детали которые лучше подтвердить, чем оставить за кадром.
    Кроме того, какой характер ключа из 4 байтов, это число или бинарная конструкция, если бинарная, приемлемо ли его перевести к типу Integer, это существенно для скорости индекса.
    ---
    Если же индекс уже создан, и не показывает результаты, которые Вы ожидаете, детали запрошенные выше помогут разобраться.
    Ответ написан
    Комментировать
  • Как сделать поиск по регулярному выражению SQL?

    @Miron11
    Пишу sql 20 лет. Срок :)
    У Вас есть 2 основных подхода
    1. через 2 выражения пользуясь операторами перечисленными здесь
    https://dev.mysql.com/doc/refman/8.0/en/regexp.html
    Возможно не всеми в любой комбинации, но существенно то, что один оператор должен найти часть последовательности символов, которые должны ответить, например
    SELECT *
    FROM `post`
    WHERE
    -- 1-е выражение
    `description` LIKE 'itemid=34543%'
    -- 2-е выражение
    AND
    `description` NOT RLIKE 'itemid=34543[0-9]+'

    2. через 1 регулярное выражение, очень похожее на то, которое Вы предложили, но видимо с \ ( backslash ) символом проведенным дважды, на той же странице объясняется почему: "Because MySQL uses the C escape syntax in strings (for example, \n to represent the newline character), you must double any \ that you use in your expr and pat arguments."
    Если по той или иной причине выражение артачится, наверное можно воспользоваться выражением на один символ длиннее, для выражения цифр [^0-9]
    Ну и наверное надо воспользоваться плюсом, а не звездочкой справа [^0-9]+, иначе эта часть становится не обязательной, и запрос может выбрать, например, значение 'itemid=34543'
    ---
    Всего хорошего!
    Ответ написан
    Комментировать