SQL *

Сразу оговорюсь, это не обучающий пост и не провозглашение новой парадигмы )), скорее решение, к которому я пришел, и хочется его обсудить в широкой и честной дискуссии.
Теперь к сути, представьте, что есть некая ORM, написанная на PHP, в которой описана модель Posts, имеющая связи многие-ко-многим через промежуточные таблицы с другими моделями: Comments, Tags, Categories. Вопрос в том, каким способом лучше поднимать связанные данные, всё сразу или с отложенной загрузкой?

Вступление

Идея написать свое приложение под Android пришла мне на пятый день отдыха в солнечном Таиланде. Не буду вдаваться в подробности что именно натолкнуло меня на неё, как и что я задумал за приложение (просто статья не об этом). Однако идея крепко укоренилась и на шестой день пребывания, воспользовавшись бесплатным интернетом в отеле, на ноутбук, взятый только ради просмотра фильмов и скидывания фотографий с фотоаппарата, я закачал MySql.
Начал я, как вы наверное уже догадались, с реляционный модели.
Работа шла трудно, но через пару месяцев с моделью я закончил и окунулся в дебри разработки под Android. До этого, под мобильные платформы я писал только на .Net Compact Framework, но так как с Java был знаком не понаслышке, накидать простенькую форму с кнопками труда не составило. Объектная модель, ожидаемо, трудностей не вызвала вообще и я, радостно предвкушая как сейчас мои тестовые данные улетят куда-то в недра устройства, открыл раздел Data Storage на сайте Android Developers. Раздел Using Databases нельзя назвать исчерпывающим, однако все необходимы ссылки на API он содержит, и я принялся писать своего наследника от SQLiteOpenHelper. После пары удачных проб, разбалованный Entity Framework’ом, я понял, что и тут бы было неплохо использовать какой-нибудь orm, так как сущностей у меня набралось больше десятка. Вбив в Великом и Ужасном «android orm», первую же ссылку я получил на эту статью, и несколько полезных на StackOverflow. Набрав в общей сложности три orm’а, я приступил к экспериментам.

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

Ощутите переполняющее чувство радости того, что вы вставляете свою собственную строку в таблицу «rows»!

При разумном выборе SQL-запросов вы вскоре получите трех- или даже четырехзначное число в одном из полей своей строки! На этот случай знайте: в игре идет самая настоящая война. В новых запросах вы сможете использовать эти числа для вычитания из строк других игроков — при этом номера в вашей собственной строке станут еще выше!

«Caché предоставляет программистам свободу в выборе способа хранения и доступа к данным через объекты, SQL, либо путем прямого доступа к многомерным структурам данных. Независимо от способа доступа, все данные в базах данных Caché хранятся в многомерных массивах.»
Технологический справочник Caché

«Глобалы (глобальные хранимые переменные) – абстракция B-tree структур, используемых в MUMPS для хранения больших объемов данных.»
A Universal NoSQL Engine, Using a Tried and Tested Technology

В статье — пара примеров создания SQL проекций на различные структуры глобалов.

В PHPStorm есть встроенная возможность подключения автодополнения имен таблиц и полей в редакторе кода, однако не все об этом знают.



Если у вас код отображается примерно так, то прошу под кат.

Цитаты из википедии (1NF):

Каждое пересечение строки и столбца содержит ровно одно значение из соответствующего домена (и больше ничего).

Одно и то же значение может быть атомарным или неатомарным в зависимости от смысла этого значения. Например, значение «4286» является

• атомарным, если его смысл — «пин-код кредитной карты» (при разбиении на части или переупорядочивании смысл теряется)
• неатомарным, если его смысл — «набор цифр» (при разбиении на части или переупорядочивании смысл не теряется)

В данной статье будут рассмотрены стандартные способы ускорения SQL-запросов по следующим типам полей: строка, дата, простой список (в формате $LB), коллекции-cписки и коллекции-массивы.

SQL инъекции, подделка межсайтовых запросов, поврежденный XML… Страшные, страшные вещи, от которых мы все бы хотели защититься, да вот только знать бы почему это все происходит. Эта статья объясняет фундаментальное понятие, стоящее за всем этим: строки и обработка строк внутри строк.

Связь многие ко многим и MS SQL Server Analysis Services

Данный пост я хочу посвятить такой, как выяснилось, несложной проблеме, как обработка OLAP-кубом связей многие-ко-многим с помощью MS SQL Server Analysis Services.

Эта статья — частичный перевод одной интересной статьи с sqlite.org, в которой подробно рассматривается реализация транзакций в SQLite. На самом деле я очень редко работаю с SQLite, но тем не менее мне очень понравилось это чтиво. Поэтому если хотите просто развить кругозор — будет интересно почитать. Первые две секции не включены в перевод, так как там нет ничего интересного, да и мне лень их набивать (пост и так огромный).

3.0 Однофайловый коммит

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

3.1 Начальное состояние

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

У нас, как и во многих других организациях, проводится тестирование соискателей при поступлении их на работу. Основу тестирования составляет устное собеседование, но в некоторых случаях, даются также практические задания. Несколько дней назад, Руководство попросило меня подготовить набор задач на знание SQL.

Раньше мне часто приходилось собеседовать людей на различные позиции, большая часть из них были разработчики приложений и баз данных. Процесс этот довольно утомительный, т.к. программисты люди смелые, творческие, любознательные и целеустремленные.
В моей практике были всякие вопросы. В статье я выделю три основных типа и расскажу, на чем я в итоге остановился и почему.

Начало см. часть 1, часть 2.

Вторичные индексы

В реляционных базах данных вторичные индексы задаются как правило при определении таблиц, или после с помощью ALTER TABLE. Если индекс определён, то он автоматически создаётся, а потом поддерживается и пересчитывается базой данных при изменении данных.

В MUMPS индексы обслуживаются явно программистом, например, в функции обновления таблицы.

В январе месяце этого года мы анонсировани книгу Сергея Тарасова "Дефрагментация мозга. Софтостроение изнутри" (http://habrahabr.ru/company/piter/blog/165327).
Прошло положенное время и книга вышла в свет.

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

Начало см. часть 1.

Глава 2. SQL/реляционные БД против MUMPS

В этой главе будут изложены основные различия между обычными SQL реляционными базами данных и БД на основе MUMPS.

Прочитайте главу 1, если вам нужно лучше понять что такое глобалы и как делаются манипуляции с ними.

Данной статьей хотелось бы показать шаги и предложить некоторые рекомендации в процессе создания BI-решения с использованием практически всего стека BI компании Microsoft. В создании BI-решения будут использованы SQL Server, SQL Service Integration Services, SQL Server Analysis Services.

Для примера мы выбрали разработку нашей компании RetailIQ — BI-систему глубокого анализа чеков розничных продаж, поставок и складских запасов для сети аптек. Для общего понимания контекста темы: все данные выгружаются из учетных систем (1С, М-Аптека и т.д.), верифицируются, складываются в специальную базу данных с последующим построением многомерных OLAP-кубов. Из источников (учетных систем) с помощью ETL мы перекачиваем данные в хранилище, на основе которого строим куб, о котором дальше пойдет речь.

Всем привет, недавно задался идеей написать PHP движок для своих нужд, так сказать и уровень повысить и получить что-то полезное. Почти сразу задался вопросом, а на сколько легко можно будет его взломать? Не секрет, что взломать можно все, что угодно, но вопрос в том, на сколько это будет проблематично и каждый ли хакер сможет это сделать?

Формы

Пожалуй, самая частая уязвимость в каком-либо проекте, будь то форма для комментариев, или форма логина. Без хороших проверок, эта штука ничего не стоит.
Одна из распространенных ошибок — это сохранять все что ты получил:

foreach( $_POST as $item ){}

Любой человек может через отладчик добавить в тот же свой собственный пункт, пусть это и не дает большого взлома, но вещь крайне не приятная.

Есть концепции работы с базой, основанные на ORM, CodeFirst со своими преимуществами и недостатками. Предлагаемая здесь унификация базы основана в первую очередь на подходе Database First.

Схема базы данных приложений со сложной доменной моделью (к которым относятся системы ERP) обычно состоит из
нескольких сотен таблиц.
Поэтому на начальном этапе проектирования базы для избежания многократных дублирований и разбухания схемы важно
определиться с несколькими базовыми таблицами для хранения общих свойств базовых сущностей приложения
и все остальные таблицы уже проектировать как вспомогательные или дополнения основных таблиц.

Всем доброго времени суток. Хотелось бы поделиться интересным, на мой взгляд, опытом работы с SQLite.

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

До недавнего времени все СУБД, работающие со структурированными данными (и не только их), можно было разделить на 2 категории: хранящие записи в построчном формате и хранящие записи в поколоночном формате. Это фундаментальное отличие, влияющее на то, как строки таблиц выглядят на уровне внутренних механизмов хранения СУБД. Долгое время СУБД Teradata относилась к первой группе, но с выходом 14-й версии представилась возможность определять, как хранить данные конкретной таблицы – в виде колонок или строк. Таким образом, появилось гибридное хранение. В этой статье мы хотим рассказать о том, зачем это нужно, как это реализовано и какие преимущества дает.