Шурутов Михаил @shurutov
Инженер по эксплуатации вычислительной техники.
Информация
- В рейтинге
- Не участвует
- Откуда
- Красково, Москва и Московская обл., Россия
- Зарегистрирован
- Активность
Специализация
Database Administrator, Инженер по эксплуатации вычислительной техники и автоматизированных систем
Lead
От 500 000 ₽
Git
Linux
Nginx
High-loaded systems
Database
Bash
PostgreSQL
Docker
LDAP
Тесты на проде...
Остановите Землю, я сойду!
Остальное лишнее. К проду у разработчиков не должно быть доступа вообще в общем случае. А частности рассматриваются отнюдь не в публичном пространстве. Но даже в частных случаях у лиц, не являющихся админами БД, должен быть только и исключительно доступ на чтение. Безо всякой записи/модификации/удаления.
Миграции - соответствующим инструментом, под соответствующим аккаунтом.
Куда ж они делись-то? Лазерные МФУ - вполне себе домашнее устройство, причём, лично у меня используется на всю катушку: и принтер, и копир, и сканер. Для д/с и/или школы печатать приходится достаточно.
Когда я читаю про оторвать доступ к данным администратору (СУ?)БД, особенно в постгресе, меня интересует только один вопрос: как
EXPLAIN (ANAYZE, BUFFERS...)
запускать? В среде нагрузочного тестирования? Не пойдёт, ибо встречался с ситуациями, когда в указанной среде всё в порядке, а в проде у СУБД крыша съехала. Да даже просто переключение роли мастера с последующим перезапуском заглючившего экземпляра решало проблемы с производительностью.Table not found будет. Если вы ранее не создавали эту таблицу специально. Что же до БД - это с какого перепугу она вся из себя такая главная? Обыкновенная БД, не более того.
Утверждение 1. Данные обычно лежат в базах данных (БД).
Утверждение 2. Базы данных, как правило, управляются системами управления базами данных (СУБД).
Следствие из утверждений. Для анализа данных необходимо применять тот язык, который понимает СУБД, управляющая БД (постгрес, например, понимает не только свой диалект SQL, но и ещё что-нибудь, что посчитали нужным включить в поставку разработчики дистрибутива).
А описанные выше ЯП — они больше для визуализации уже обработанных данных, за исключением SQL.
А желание обрабатывать данные вне СУБД для меня, как АБД-инженера по эксплуатации, является совсем непонятным.
Сразу, varchar(n) vs text: https://ru-postgres.livejournal.com/65930.html
И, естетсвенно, официальная вики по постгресу: https://wiki.postgresql.org/wiki/Don't_Do_This#Don.27t_use_varchar.28n.29_by_default
В те времена далёкие, теперь уже былинные (с) В.С.Высоцкий (почти), к узлу графа могло подключаться существенно больше рёбер, нежели предыдущее и следующее. А в неориентированном графе понятия "предыдущее" и "следующее" вообще смысла не имеют.
И тут же рядом лежит БД в формате КЛАДР 4.0. В dbf...
Дальше читать нет необходимости. Но я себя пересилил. Дошёл до:
Понимание необходимости обновления (первый комментарий, однако) отсутствует, как класс. Помимо уже сказанного явно отсутствует какая-нибудь отказоустойчивость, т.е. накрылась железка, производство встало. Всё, дальше уже просто неинтересно.
Это держание ограничено по времени. Точно говорю, ибо опыт имеется. Увы и ах - либо задняя стенка из оргалита/фанеры, либо металлические уголки.
Но за идею - спасибо, интересно!
Правда, мне больше подойдёт стационарная тумба (планировка такая, однако).
Без Duke Nukem 3D обзор выглядит неполным. С моей личной точки зрения. И Quake до нас (Алтай, Барнаул) дошёл несколько попозжее, нежели Дюк. И ещё, если мне память не изменяет, Дюк был не такой требовательный к ресурсам.
Премного благодарствую!
Не увидел на картинке, хоть тресни... :(
Вдогон к https://habr.com/ru/post/692600/#comment_24809968
https://towardsdatascience.com/can-we-stop-with-the-sql-joins-venn-diagrams-insanity-16791d9250c3
Собственно, всё остальное - просто приятное (кому как, однако) чтиво для немного отвлечься.
Побуду-ка я ноликом здеся (или тута? я в душе не ведаю, как правильно), ибо реакция более, чем красноречивая.
Спасибо, интересный материал. Хорошо и вкусно написано, приятно почитать, посмотреть на себя молодого со стороны. И поностальгировать.
Дальше не читал - неинтересно, потому что автор явно знает рускава езыка. Пишет - соответственно. Слова "разговор", "диалог", "беседа" - не, не знаю.
PS. По теме же - не надо пытаться понравиться компании. Не надо пытаться готовиться к собеседованию. Два ключевых навыка: понимание своего реального уровня и умение подать и, когда необходимо, подать/обосновать свой уровень. Всё! Даже когда ваш технический уровень не дотягивает до требований, но вы данный факт осознаёте, понимаете, что придётся попахать, готовы пахать, и грамотно всё это подаёте - вероятность трудоустройства далека от нуля. Ну а провал собеседования - ничего страшного, смотрите на подобный результат, как "не моя компания, оказывается, на самом деле."
https://hsto.org/r/w1560/webt/9a/eu/ny/9aeunyfxduikztrt4krfu7uutew.jpeg - HP elitebook 8440p, весной будет 11 лет, как дома трудится.
Средства для бекапа ПГ рассмотрены вот здесь: https://ru-postgres.livejournal.com/66359.html
Предложенное же решение - это рукоблудие и скриптоложество, полезное только автору для набить руку в bash-е, не более того.
Это свойство называет закон транзитивности, а не какая-то неведомая трансляция. :(