Зачем вообще выбирать базу данных? Почему нельзя просто взять ту, с которой уже работал, и использовать ее? Часто это оправданный выбор, но для чего же тогда создано почти 500 разных СУБД? Давай попробуем разобраться вместе, чем они отличаются и когда нужны.

Раз в квартал у PostgreSQL выходит минорный релиз с парой уязвимостей. Обычно все просто — накатываем патчи в момент выхода обновления и спим спокойно. Однако большинство форков остаются уязвимыми! Я прошелся по историческим CVE «Постгреса» в поисках интересных лазеек и нашел там очень много интересного.

Облачная база данных — штука удобная: считай, вся работа по деплою и настройке сервера за тебя уже сделана, осталось только пользоваться! Админов это расслабляет настолько, что такие базы часто остаются незащищенными и ищутся с помощью поисковиков. Один нюанс — этим поисковиком не может быть Google!

Практически каждый день «Хакер» пишет о масштабных и не очень утечках данных. «Течет» откуда только можно, и последствия бывают самыми разными. Сегодня я постараюсь рассказать и показать, как легко злоумышленники могут получить доступ к обширным массивам всевозможных данных.

К угрозе «Я тебя по IP пробью!» сегодня не стоит относиться с излишним скепсисом: пробить по IP действительно могут. А еще по номеру телефона, банковским реквизитам, ФИО и даже по фотографии. И речь не о полиции и ФСБ: все это успешно делают киберпреступники, за которыми закрепилось название «пробивщики».

Есть разные способы показать пользователю только те данные, которые ему нужны. Row level security — один из самых универсальных, простых и надежных. Прочитав эту статью, ты поймешь, что это несложно, и научишься организовывать разграничение доступа к записям средствами самой БД без особого ущерба для производительности.

Что нужно, чтобы быстро заглянуть в базу данных и найти там что-нибудь? Можно написать запрос из командной строки, использовать десктопный клиент или на скорую руку добавить страницу к веб-приложению. Разработчики Franchise предлагают еще один способ — воспользоваться их готовым вебовым клиентом.

В Android-приложениях есть возможность хранить большой объем данных в собственной, скрытой от посторонних глаз БД. Ты удивишься, насколько это может быть полезно и, самое главное, легко!

SQLite — очень популярное решение хранения данных, и операционная система Android не исключение. Сама система и многие программы используют для хранения информации базы данных - файлы с расширением db. Какие именно данные содержатся в базах, как их посмотреть, что с ними можно сделать и чем это грозит устройству с правами суперпользователя — обо всем этом я расскажу в статье.

Персональная СУБД FileMaker больше тридцати лет развивалась на платформе Apple и почти не уступает Microsoft Access по возможностям. Зато она имеет несколько любопытных особенностей, которые делают этот продукт доступнее для непрофессионалов и позволяют за минуты создать действующий прототип приложения для iPhone или iPad.

Серверы баз данных — одни из ключевых в любой организации. Именно они хранят информацию и предоставляют выдачу по запросу, и крайне важно сохранить БД в любой ситуации. Базовая поставка обычно включает нужные утилиты, но админу, не сталкивавшемуся до этого с БД, придется некоторое время разбираться с особенностями работы, чтобы обеспечить автоматизацию.

Как бы тебе ни хотелось, MongoDB не подходит в качестве основной БД для 90% приложений. Причина банальна, и ты не раз слышал о ней — почти все данные, которыми оперирует, скажем, среднестатистический сайт, реляционны. А это значит, что даже при использовании ORM работа с Монгой со временем превратится в лапшу из запросов, популяций и ручного копания в результатах. Но что делать, если тебя все же угораздило заюзать ее в своем проекте? Остается только расслабиться и получать удовольствие. А какое удовольствие может быть без толковой админки?

Несколько лет назад оказалось, что SQL внезапно устарел. И начали появляться и множиться NoSQL-решения, отбросившие язык SQL и реляционную модель хранения данных. Основные аргументы в поддержку такого подхода: возможность работы с большими данными (те самые Big Data), хранения данных в самых экзотичных структурах и, самое главное, возможность все это делать очень быстро. Давай посмотрим, насколько это получается у самых популярных представителей мира NoSQL.