Check Levi9 best QA positions to Backbase team!
×Закрыть
  • Основные заповеди программиста

    Мне не нужно спрашивать у ораклистов, я сам в Оракле неплохо разбираюсь :) ... и кстати, писал логику на PL/SQL там, где это нужно было, при этом не могу сказать, что это вызывает проблемы.

    А вообще, насколько я понимаю, этот разговор не имеет смысла — Вы не только плохо разбираетесь в базах данных (по крайней мере как минимум в Oracle, Postgre, MSSQL), но и в железе у вас явно знания не на уровне промышленных серверов. Более того, у Вас и со чтением проблемы :) - по крайней мере для того, чтобы понять фразу «я как-то смотрел один проект» как то, что я этот проект делал... нужно обладать плохим вниманием и хорошей фантазией :)

  • Основные заповеди программиста

    Ага, я уже такое проходил — помнится я как-то смотрел один проект, в котором первой базой был выбран HSQLDB, с целью перехода в дальнейшем на что-то более серьезное. В общем повезло, что собственно содержимое базы оказалось никому не нужно, потому что при перевести на другую базу перелитием данных было нельзя. В этой HSQL foreign key как бы были, но не контролировались. В итоге ссылки в никуда, записи, на которые никто не ссылается. Я так понимаю, что Вы рекомендуете именно это? На вопрос: «а почему они не написали контроль в беке», ответ — «а кто будет платить за написание дополнительного кода, который дублирует существующий функционал базы?» Да, код конечно был не очень, но при включенных проверках в базе проблем бы ни у кого не было

    Ага, а в БД значит тонкой настройки кеша нет? :)

    Все-таки я вам бы советовал во-первых, немного почитать о БД, а во вторых, интересоваться современным железом :) - Сейчас большая часть производителей хранилищ данных как раз и продвигает хранилища на SSD... больше того, они уже и хранилища на NVME предлагают (Huawei например). А по поводу ненадежности SSD — во-первых, промышленные SSD и домашние это таки немного разные вещи, а во-вторых — в таких случаях обычно всегда есть RAID10, особо жадные ставят базы на RAID6, а особо параноидальные вообще делают что-то типа RAID60 :)

    Поддержали: Oleksiy Antonov, Gennady Dogaev
  • Основные заповеди программиста

    Предлагаю дальше развить Вашу мысль: проверки на бекенде являются атавизмом и не нужны, потому как практически все проверки можно сделать на фронте и там они так или иначе делаются. Или наоборот — проверки на фронте не нужны, потому что проверок нужно гораздо больше, чем можно не фронте сделать :) В обоих случаях мы выигрываем ресурсы — Вам какой вариант больше нравится? :)

    На самом деле мы занимаемся демагогией — я говорю: вот есть приложения типа А, в них желательно делать так, а есть B, в них можно немного по другому. Ваши возражения — это все неправильно, потому что в приложениях типа C нужно совсем по другому.
    Например: в каких приложениях нужна сложная обработка ошибок БД? В 95% приложений достаточно сказать: «ой, что-то не получилось, зайдите позже», а админам в это время система мониторинга скажет, что с базой что-то не то. В оставшихся 5% возможно что-то и нужно... но ведь в 5%, а не 100%.

    Я правильно понимаю, у вас обычно серверы приложений на многоядерных Xeon с минимум 1TB памяти, а серверы БД на Raspbery или Arduino с соответствующими ресурсами? :) Иначе я себе слабо представляю тягу отключить использование индексов на primary key (а foreign key их в основном и использует), а также кеширования в БД.

    Поддержали: Oleksiy Antonov, Gennady Dogaev
  • Основные заповеди программиста

    По поводу цены — сравним решения:
    1. есть foreign key, проверки делаются постоянно при вставке/обновлении, но осуществляются внутренними механизмами базы
    2. foreign key нет, но есть проверки на каждую вставку/обновление: нужно сделать запрос на клиенте, сериализовать его, распарсить на сервере, построить план (если его еще нет), достать данные (те самые внутренние механизмы), сериализовать их, передать клиенту, там десериализовать...
    3. вообще не делать проверок

    Понятно, что вариант 3 самый быстрый... но допустим мы все-таки проверки делаем :) - Вы считаете, что вариант 2 быстрее, чем 1?

    Поддержал: Gennady Dogaev
  • Основные заповеди программиста

    Переносимости куда? Если с одной базы на другую, то... не то, чтобы геморно, но учитывая, что сам Postgre компиляцией не занимается, для процедур на C ему нужен бинарник, то да, запихнуть код процедуры во что-то типа Flyway не получится... но мы же говорили о принципиальной возможности, а не о том, как переносить.

    По поводу проверок на уровне сервера приложений — тут как раз не согласен... т.е. да, проверки нужны, но... Проблема в том, что сейчас как раз большинство приложений делаются в виде сервер/кластер серверов -> одна база. Соответственно есть два варианта:
    1. свести проверки, которые могут быть сделаны в базе — на уровень базы, т.е. минимизировать траффик и выборки, соответственно выиграть те самые время и деньги
    2. делать все проверки на сервере приложений — и тут начинаются изобретения типа SAGA, EDD и т.п. в тех местах, где оно совсем не нужно, т.е. теряем время на разработку и отладку вещей, без которых все и так будет работать, т.е. те же деньги
    Да, есть highload или olap приложения, где нужны уже другие подходы... но сколько у нас тех приложений?
    По-моему где-то тут была статья с примерно таким диалогом:
    — у нас распределенная система, 7 серверов...
    — а какое у вас максимальное количество записей в таблице?
    — 70000
    Другая статья, «у нас highload система, 20кк транзакций в месяц, 100 серверов»... а 20кк транзакций в месяц это, если я правильно посчитал — 7 транзакций в секунду, для правильно написанного приложения хватит одного сервера и еще ресурсов на вырост останется

    При том, что для того же highload обычно нужны точечные решения — в паре таблиц немного поменяли подход, вынесли их отдельно куда-то в nosql, остальное работает по общим правилам

    Поддержал: Gennady Dogaev
  • Основные заповеди программиста

    и мы уже ограничились PostgreSQL, во веки веков

    Как бы Вам сказать... есть такая вещь, как пример, это когда применяют частный случай для объяснения общего :) Не нравится Postgre, тогда есть еще MSSQL — там процедуры можно писать на любом языке, поддерживаемом CLR...

    А хранимую процедуру можно на C написать??

    Понимаете, Вы упорно демонстрируете свое же утверждение по поводу образования — если бы Вы хотя бы немного были знакомы с тем же Postgre (а человек, который утверждает, что знаком с базами данных, должен иметь представление хотя бы о первой пятерке БД), то не задавали бы таких вопросов. Один из разделов его документации начинается фразой: «User-defined functions can be written in C»

  • Основные заповеди программиста

    А до конца это как? Вот я например как-то получил таки высшее образование, поработал, потом, через какое-то время, защитился и получил PhD — должен ли я считать людей без PhD необразованными? О, кстати, Вы подали хорошую идею — предлагаю в начале каждого обсуждения писать свое образование, автоматически в споре побеждает тот, у кого его больше :)

    > Фраза что индексы лишены нормализации означает, что они обслуживают данные за границами их вылизанной фундаментальной теории
    Еще раз — индексы не являются участником общей концепции хранения данных, это вспомогательный механизм в конкретной реализации БД, его отсутствие на саму концепцию никак не влияет. Покажите мне хотя бы одно упоминание индексов в описании нормальных форм (на всякий случай: ключ — не индекс).

    По поводу хранения неструктурированных данных — ну так есть оно уже: в куче баз есть возможность хранить строки, который потом представлять как XML, JSON и т.п., после чего проводить операции с отдельными полями... и все это на уровне SQL — вроде именно то, что Вы и хотели. Данные с архивацией — тут уже не помню, может у кого-то и есть... если нет, то да, придется писать плагин к базе. Ну или брать честный фреймфорк, который вытянет все 10ТБ данных, разархивирует каждую запись, отфильтрует, и на выходе отдаст 1КБ данных :)

    Поддержал: Gennady Dogaev
  • Основные заповеди программиста

    Нет, мы честно пишем исключение в лог/шлем сообщение куда-то и все. Дальше условный менеджер заводит в условной jira таску, исходя из которой условный программист разбирается, почему в данном случае что-то не сработало. Примерно в половине случаев окажется, что пользователь ввел что-то неправильно, но этот ввод пропустила проверка на входе в приложение. С моей точки зрения это лучше, чем потом разбираться, почему следующей ночью крон по контролю целостности базы скажет, что что-то у вас с базой не так, деньги ушли не туда, в сеть подали не 220, а 300 вольт, больному вкололи 20 кубиков аминазина и т.п.

    > Я не говорю, что базы лишены программиорования. Лишь утверждаю, что это либо через жопу делается, в сравнении с честными языками и фреймворками на них
    Исходя из этого считаем, что C, Perl, Python, Tcl — языки заведомо нечестные (на всех них можно писать триггеры и остальную логику например на PostgreSQL). А можно тогда список честных языков и фреймворков, а то вдруг я не тем занимаюсь? :)

    > И вот в этом случае, коих, повторюсь, большинство нынче — и стоит исключить лишнюю работу из базы...
    И вместо использования встренного функционала базы писать свой код по контролю целостности... как-то это расходится с призывом оптимизировать ВРЕМЯ и ДЕНЬГИ.

  • Основные заповеди программиста

    С одной стороны согласен, с другой — лучще переформулировать и сместить акценты: образование и опыт нужны чтобы знать когда МОЖНО нарушать правила и когда этого делать НЕЛЬЗЯ. Потому как из Вашей фразы следует: «у меня высшее образование, поэтому я выше правил, которые придуманы для всяких лохов» :)
    Не совсем понял высказывание про индексы и про то, что они лишены нормализации — какое отношение индексы имеют к хранению данных? Это всего навсего дополнительная функциональность для ускорения работы с данными, соответственно требовать от них нормализации примерно то же самое, что требовать от ложки быть съедобной — мы же едим с ее помощью, значит она имеет отношение к еде. И работать с базами без индексов никто не запрещал — full scan еще никто не отменял... более того, если Вы работаете с базами, то должны помнить, что на маленьких таблицах индексы наоборот противопоказаны, потому что замедляют работу

  • Основные заповеди программиста

    Целиком согласен, зачем использовать встроенные проверки, если можно писать триггеры для тех же проверок на уровне сервера приложений... подумаешь, ну придется писать гораздо больше кода, придумывать синхронизацию, если серверов больше одного, мы же не ищем легких путей, и платят нам за количество строк кода, а не за функционал :)
    А Ваша фраза, что «Базы попросту лишены адекватных возможностей программирования» говорит о том, что с базами данных Вы не слишком часто сталкивались :) - да, сейчас принято выносить всю логику на сервер приложений, потому как это как минимум проще масштабировать, но утверждать, что в них нет адекватных возможностей программирования... А потом, после таких вот советов, народ тащит эти миллионы записей на сервер приложений, чтобы отфильтровать их там и получить на выходе пару десятков записей.

    Поддержал: Oleksiy Antonov
  • Основные заповеди программиста

    Это серьезно, по поводу foreign key? А что делать, если эта задача обнаружит нарушение целостности? К примеру у нас уже операция завершилась, деньги ушли, но запись в базе ссылается непонятно на что, потому что разработчик решил, что foreign key не нужны...
    Вы уж скажите, с какими продуктами работаете, чтобы знать, чего опасаться :)

  • Введение в GraphQL: что это за язык и как использовать его под Android

    В данном случае идет обсуждение GraphML vs REST и JSON-RPC это просто пример того, что подобный принцип не является изобретением GraphML, а уже был реализован в REST

  • Введение в GraphQL: что это за язык и как использовать его под Android

    Насколько я помню, RPC это просто общий принцип, который может быть реализован с помощью разных протоколов. Одним из вариантов реализации как раз и является JSON-RPC. А то так можно сказать, что SOAP никакого отножения к RPC не имеет, потому что в его названии нет этих букв... или что например PostgreSQL не имеет никакого отнощения к SQL, потому что сам SQL возник задолго до PostgreSQL :)

  • Введение в GraphQL: что это за язык и как использовать его под Android

    Кстати, в REST такое уже придумали, называется JSON-RPC, и спецификация есть :)

  • Введение в GraphQL: что это за язык и как использовать его под Android

    А мне казалось, что CREATE ROLE, GRANT и т.п. уже в SQL-92 были :)

  • Введение в GraphQL: что это за язык и как использовать его под Android

    То есть получается, что ради одного поля нужно делить типы на два, писать для каждого резолверы, мутаторы и т.п... а если таких полей будет два, оба с разными правами? Ниже подсказали вариант со scope, но этого в стандарте вроде нет.
    В как для меня, GraphQL имеет смысл только в случае открытого API, когда ты не знаешь, кто будет клиентом, если это продукт, для которого пишется как фронт так и бек одной командой, оно явно избыточно

  • Введение в GraphQL: что это за язык и как использовать его под Android

    Посмотрел, действительно через scope это можно решить... только, если я правильно понимаю, это кастомное расширение, т.е. не прописано спецификации

  • Введение в GraphQL: что это за язык и как использовать его под Android

    Как бы да... но выше я уже описал пример, когда использовать поля внутри бекенда данной роли пользователя можно, а вот отдавать на фронт — нельзя. Т.е. для REST, как вариант, это будут два разных эндпойнта, соответственно возможность обращения к ним определяется ролью, т.е секьюрити компонент это просто набор соотвествий эндпойнт->роль. В случае GraphQL в этом секьюрити компоненте нужно проверять все поля, которые есть в запросе и, в случае появления нового поля расширять проверки.
    Т.е. теоретически это все сделать можно, либо нужно кучу усилий потратить на безопасность, либо с тем же успехом можно SQL с фронта пробрасывать :)

    Поддержал: Gennady Dogaev
  • Введение в GraphQL: что это за язык и как использовать его под Android

    Понятно, что бекенд, но если позволять только запросы с определенной структурой, то это уже есть, называется REST :)
    На примере того же форума: есть два вида пользователей, у одного есть права администратора и он может смотреть и/или изменять email других пользователей в группе (но только в своей), у другого права посмотреть email нет, но при этом если один пользователь пишет ответ другому, то на email уходит оповещение.

    Поддержал: Gennady Dogaev
  • Введение в GraphQL: что это за язык и как использовать его под Android

    В том-то и дело, что client1 может получать это поле, а client2 — нет, роли у них разные, т.е. потенциально запрос может возвращать поля... но не для всех

    Поддержал: Gennady Dogaev
← Сtrl 12 Ctrl →