Пошло ещё с 70х годов, когда кроме stored procedures альтернатив написанию кода для банковских транзакций не существовало. На сегодняшний день ситуация такая, что практически по всем банкам расползлась одна и та же кодовая база.
Легаси в тысячи человеко-лет. Возможно, они бы и хотели переписать всё, но переписывание такого объёма - это гарантированный [роскомнадзор].
Банки кушают этот кактус, потому что у них выбора нет. Зачем приводить их в пример, не учитывая историю айти в банках?
Вы уверены, что это хороший пример? Или это просто карго-культ, раз большие и богатые банки так делают, значит это правильно?
Мысль интуитивно понятна, наврядли кто-то найдёт статью про это. Это тот кейс, про который я рассказывал: нельзя пропускать строки. Вся статья, которую бы я написал, сведётся к следующей строке:
SELECT * FROM table WHERE ID > last_id LIMIT :limit:
к моменту выполнения второго запроса данные могут стать неактуальными
Данные могут стать неактуальными в то время, когда результат запроса летит к пользователю. В то время, когда пользователь их читает. Собственно, для того, чтобы показывать данные, такой трюк не поменяет примерно ничего.
Да, есть ситуации, когда нужно пагинировать данные для сервиса, разбивая большую таблицу на батчи, но здесь непременное условие - не пропустить ни одной строки. По вашему алгоритму между запросами страниц может быть удалена строка из текущей страницы, после запроса которой курсор сместится на количество удалённых записей вперёд. Это касается любых алгоритмов, основанных на row_id.
некую универсальную процедуру для демаршалинга
Под демаршаллингом подразумевается маппинг данных из таблицы в поля класса?
Я думаю, что решение в том, чтобы рассматривать M*N-1 черепах, одновременно работающих в SIMD. Алгоритм на каждом шаге должен выбирать тот путь, который максимально сокращает количество занятых клеток, помещая черепах в одну. И так, пока все не окажутся в одной. Далее задача сводится к доползанию до финиша толпы черепашек.
Прочитав текст, я сделал вывод, что под "естественным" ключом подразумевается ключ из чужой ИС. Собственно вывод предсказуем: не доверяй никому. Особенно так делать нельзя, если планируется держать данные из разных сторонних ИС.
Не тремя. Даже не десятью. Нужно создать временную таблицу, перенести все данные, убрать индексы, убрать констрейнты, убрать внешние ключи, убрать триггеры. Дропнуть таблицу, переименовать временную, вернуть индексы, вернуть констрейнты, внешние ключи, пересоздать триггеры.
Вот чтобы всё это сделать нужно заморочиться. А чтобы это сделать без ошибок и для общего случая, нужно заморочиться сильно, прям очень сильно.
Почему ваше представление должно быть единственно правильным
А и не должно быть. Это вообще-то подмена тезиса. Я говорю про ВОЗМОЖНОСТЬ упорядочивания колонок, а вы мне про эгоцентризм. Если работаешь с людьми - тогда учитывай интересы людей.
Я обычно работаю над проектом один, и в этом режиме мне абсолютно плевать на мнение коллег о структуре данных.
Да, классная фича, оценил. В своё время я отказался от DG из-за одной "фигни", которая критична для меня. Мне нужен список полей с комментариями внутри таблицы. Этого в DG нет или я не нашёл.
Мне понравилось, как именно перетаскиваются колонки. Прямо вместе с мясом. Я себе так же сделаю.
Это проблема БД, потому что она хранит структуру таблиц. Внешние инструменты будут вынуждены синхронизироваться с ней и хранить данные о порядке вне структуры.
В любом случае есть факт. MySql позволяет встроенным синтаксисом менять расположение колонок, а оракл/мс/постгрес - нет. Вот и всё. Не надо мне доказывать, что мне это не нужно. Не надо предлагать костылями подпереть. Не надо скидывать ответственность на другие инструменты.
Я упорядочиваю столбцы по их функционалу для того, чтобы снизить когнитивную нагрузку при работе с данными, а вы предлагаете насоздавать вьюшек на каждую большую таблицу, чтобы потом следить за соответствием этих вьюшек таблицам. Я не враг себе, мне такие костыли не нужны.
Плюс к этой процедуре надо написать интерфейс для удобного редактирования структуры таблицы, чтобы можно было драгдропом поменять местами колонки. Потом механизм сопоставления версий структур данных для генерации миграций. Ну и сразу удобный data management, чтобы можно было в одном месте и данные в таблице поменять )
Хорошая идея. Я этим как раз и занимаюсь. Но это дорого и долго.
Очень странный аргумент. Почему базу данных должен беспокоить простой бизнеса? Это вообще не её, базаданново дело. Она понятия не имеет, используются эти таблицы или нет. Насколько критичен простой именно сейчас, и вообще может быть сейчас выходной.
БД - инструмент разработчика. Разработчик делает инструмент для бизнеса. И позвольте разработчику самому решать, какая должна быть структура данных.
Я часто работаю с "сырыми" данными в sql, когда надо быстро посмотреть, в каком состоянии находятся объекты. Иногда таблицы довольно большие, 20, 30 и иногда 100+ столбцов. Мне УДОБНО, когда столбцы, относящиеся к одному функционалу находятся рядом, тогда не приходится скроллить таблицу или изобретать вьюшки на каждый случай. А на каждый случай вьюшек не напасёшься.
О, как. MySql оказывается несерьёзная. И в каком месте она несерьёзная?
Если стоит задача хранить реляционные данные и получать к ним доступ, то чем плоха MySql? Я вот по наивности считал, что именно хранение данных - это первейшая задача СУБД.
Тот же оракл не имеет интовых типов данных. Да, там есть INTEGER, для совместимости с SQL'92, но это тот же самый number(0, 38). То есть число с переменной длиной, которое не запихнёшь с гарантией ни в один из типов современных бэкенд-языков. Это признак серьёзности?
Да, ни оракл, ни постгрес, ни mssql не умеют в add column after. У всех отмазка "ну это чтобы не пересоздавать таблицу". Мне пофиг на пересоздание, у меня там три записи (или вообще нет ни одной). Почему я не могу встроенным синтаксисом вставить столбец куда мне надо? Да, мне это важно, потому что я сортирую столбцы по их назначению. Мне потом их проще искать.
Почему у оракла 30к символов ограничение в nvarchar (при флаге extended, без него 12к)? Это из серии "640кб хватит всем"? Не, я понимаю, что можно пихать текст в блобы, никто вроде не запрещает. Но у того же мускуля 64к символов в TEXT и 4ккк символов в LONGTEXT. Неужели сложно?
20+ лет назад там был myisam, так что неудивительно. Да, был был быстрый инсерт, но в ущерб надёжности, транзакционности и прочим "ненужным" вещам. Сейчас с InnoDb всё примерно как у всех. Зависит от сценария, ключей, индексов, хранилища, памяти.
По своему опыту ормостроения я понял, что для разных случаев нужны разные уровни доступа к данным. От SQL всё равно не уйти, но это не значит, что ORM не нужен.
задача "Object-Relational Mapping" решения не имеет
Небольшая поправка: не имеет решения для общего случая. Как и задача сжатия данных. Но алгоритмами сжатия пользуются
Невозможно найти единственно правильный баланс между eager- и lazy-загрузкой
Вот меня удивляет, что в гибернейте eager/lazy прибиты гвоздями в описании структуры данных. А EF тем временем позволяет явно подключать джойном данные в рантайме с помощью .Include() для каждого запроса индивидуально.
Спасибо за статью, это мотивирует самого что-то написать. Давно хотел рассказать про свою ORM, где "базы данных не существует".
Вы действительно хотите бенчмарк закешенных в клиенте данных против sql запроса по сети?
Давайте я угадаю? Это Oracle.
Пошло ещё с 70х годов, когда кроме stored procedures альтернатив написанию кода для банковских транзакций не существовало. На сегодняшний день ситуация такая, что практически по всем банкам расползлась одна и та же кодовая база.
Легаси в тысячи человеко-лет. Возможно, они бы и хотели переписать всё, но переписывание такого объёма - это гарантированный [роскомнадзор].
Банки кушают этот кактус, потому что у них выбора нет. Зачем приводить их в пример, не учитывая историю айти в банках?
Вы уверены, что это хороший пример? Или это просто карго-культ, раз большие и богатые банки так делают, значит это правильно?
Ну давайте, расскажите, как сложно разобраться с запросом, в котором есть WHERE, ORDER BY и LIMIT. У вас же код QueryBuilder перед глазами.
И заодно расскажите, почему перенос на клиента бизнес-логики заставит закупить мощное оборудование для базы данных. Ведь об этом статья.
Или Вы просто не читали статью?
При order by не существует решения вменяемой пагинации вообще-то. Я про него не забыл, я его не учитываю.
При требовании "не пропускать строки" пагинация бесполезна. Тут нужно сортировать ПОСЛЕ получения данных. Причём всех.
При показе пользователю метод last_id не нужен. Всё равно пользователь видит устаревшие данные, что там пропущено - это его проблемы.
Мысль интуитивно понятна, наврядли кто-то найдёт статью про это. Это тот кейс, про который я рассказывал: нельзя пропускать строки. Вся статья, которую бы я написал, сведётся к следующей строке:
SELECT * FROM table WHERE ID > last_id LIMIT :limit:
Данные могут стать неактуальными в то время, когда результат запроса летит к пользователю. В то время, когда пользователь их читает. Собственно, для того, чтобы показывать данные, такой трюк не поменяет примерно ничего.
Да, есть ситуации, когда нужно пагинировать данные для сервиса, разбивая большую таблицу на батчи, но здесь непременное условие - не пропустить ни одной строки. По вашему алгоритму между запросами страниц может быть удалена строка из текущей страницы, после запроса которой курсор сместится на количество удалённых записей вперёд. Это касается любых алгоритмов, основанных на row_id.
Под демаршаллингом подразумевается маппинг данных из таблицы в поля класса?
Я думаю, что решение в том, чтобы рассматривать M*N-1 черепах, одновременно работающих в SIMD. Алгоритм на каждом шаге должен выбирать тот путь, который максимально сокращает количество занятых клеток, помещая черепах в одну. И так, пока все не окажутся в одной. Далее задача сводится к доползанию до финиша толпы черепашек.
При том, что номер паспорта - это ключ из чужой информационной системы, например. Он ни в одном месте не естественный )
Прочитав текст, я сделал вывод, что под "естественным" ключом подразумевается ключ из чужой ИС. Собственно вывод предсказуем: не доверяй никому. Особенно так делать нельзя, если планируется держать данные из разных сторонних ИС.
Не тремя. Даже не десятью. Нужно создать временную таблицу, перенести все данные, убрать индексы, убрать констрейнты, убрать внешние ключи, убрать триггеры. Дропнуть таблицу, переименовать временную, вернуть индексы, вернуть констрейнты, внешние ключи, пересоздать триггеры.
Вот чтобы всё это сделать нужно заморочиться. А чтобы это сделать без ошибок и для общего случая, нужно заморочиться сильно, прям очень сильно.
А и не должно быть. Это вообще-то подмена тезиса. Я говорю про ВОЗМОЖНОСТЬ упорядочивания колонок, а вы мне про эгоцентризм. Если работаешь с людьми - тогда учитывай интересы людей.
Я обычно работаю над проектом один, и в этом режиме мне абсолютно плевать на мнение коллег о структуре данных.
Да, классная фича, оценил. В своё время я отказался от DG из-за одной "фигни", которая критична для меня. Мне нужен список полей с комментариями внутри таблицы. Этого в DG нет или я не нашёл.
Мне понравилось, как именно перетаскиваются колонки. Прямо вместе с мясом. Я себе так же сделаю.
Это проблема БД, потому что она хранит структуру таблиц. Внешние инструменты будут вынуждены синхронизироваться с ней и хранить данные о порядке вне структуры.
В любом случае есть факт. MySql позволяет встроенным синтаксисом менять расположение колонок, а оракл/мс/постгрес - нет. Вот и всё. Не надо мне доказывать, что мне это не нужно. Не надо предлагать костылями подпереть. Не надо скидывать ответственность на другие инструменты.
Я упорядочиваю столбцы по их функционалу для того, чтобы снизить когнитивную нагрузку при работе с данными, а вы предлагаете насоздавать вьюшек на каждую большую таблицу, чтобы потом следить за соответствием этих вьюшек таблицам. Я не враг себе, мне такие костыли не нужны.
Плюс к этой процедуре надо написать интерфейс для удобного редактирования структуры таблицы, чтобы можно было драгдропом поменять местами колонки. Потом механизм сопоставления версий структур данных для генерации миграций. Ну и сразу удобный data management, чтобы можно было в одном месте и данные в таблице поменять )
Хорошая идея. Я этим как раз и занимаюсь. Но это дорого и долго.
Очень странный аргумент. Почему базу данных должен беспокоить простой бизнеса? Это вообще не её, базаданново дело. Она понятия не имеет, используются эти таблицы или нет. Насколько критичен простой именно сейчас, и вообще может быть сейчас выходной.
БД - инструмент разработчика. Разработчик делает инструмент для бизнеса. И позвольте разработчику самому решать, какая должна быть структура данных.
Я часто работаю с "сырыми" данными в sql, когда надо быстро посмотреть, в каком состоянии находятся объекты. Иногда таблицы довольно большие, 20, 30 и иногда 100+ столбцов. Мне УДОБНО, когда столбцы, относящиеся к одному функционалу находятся рядом, тогда не приходится скроллить таблицу или изобретать вьюшки на каждый случай. А на каждый случай вьюшек не напасёшься.
MySql делает это ТОЧНО через пересоздание таблицы. Что я прекрасно знаю и это меня ничуть не волнует.
О, как. MySql оказывается несерьёзная. И в каком месте она несерьёзная?
Если стоит задача хранить реляционные данные и получать к ним доступ, то чем плоха MySql? Я вот по наивности считал, что именно хранение данных - это первейшая задача СУБД.
Тот же оракл не имеет интовых типов данных. Да, там есть INTEGER, для совместимости с SQL'92, но это тот же самый number(0, 38). То есть число с переменной длиной, которое не запихнёшь с гарантией ни в один из типов современных бэкенд-языков. Это признак серьёзности?
Да, ни оракл, ни постгрес, ни mssql не умеют в add column after. У всех отмазка "ну это чтобы не пересоздавать таблицу". Мне пофиг на пересоздание, у меня там три записи (или вообще нет ни одной). Почему я не могу встроенным синтаксисом вставить столбец куда мне надо? Да, мне это важно, потому что я сортирую столбцы по их назначению. Мне потом их проще искать.
Почему у оракла 30к символов ограничение в nvarchar (при флаге extended, без него 12к)? Это из серии "640кб хватит всем"? Не, я понимаю, что можно пихать текст в блобы, никто вроде не запрещает. Но у того же мускуля 64к символов в TEXT и 4ккк символов в LONGTEXT. Неужели сложно?
20+ лет назад там был myisam, так что неудивительно. Да, был был быстрый инсерт, но в ущерб надёжности, транзакционности и прочим "ненужным" вещам. Сейчас с InnoDb всё примерно как у всех. Зависит от сценария, ключей, индексов, хранилища, памяти.
По своему опыту ормостроения я понял, что для разных случаев нужны разные уровни доступа к данным. От SQL всё равно не уйти, но это не значит, что ORM не нужен.
Небольшая поправка: не имеет решения для общего случая. Как и задача сжатия данных. Но алгоритмами сжатия пользуются
Вот меня удивляет, что в гибернейте eager/lazy прибиты гвоздями в описании структуры данных. А EF тем временем позволяет явно подключать джойном данные в рантайме с помощью .Include() для каждого запроса индивидуально.
Спасибо за статью, это мотивирует самого что-то написать. Давно хотел рассказать про свою ORM, где "базы данных не существует".