Итак, поискав на хабре информацию по проектированию БД, и не найдя ничего более или менее вразумительного, я решил написать об этом небольшую статью.
Проектирование базы данных сводится к трем последовательным этапам:
Ниже я предлагаю ознакомиться с ними более детально.
Читать полностью »
Есть множество способов организации иерархического хранения данных. В последнее время меня заинтересовал вопрос по структуре каталога, например, интернет-магазина. А именно, когда Группы и Товары хранятся в разных таблицах.
При навигации посетителя по Группам, должны выводиться Товары из всех Подгрупп.
Хотелось бы, имея код Группы, получить быстрый запрос к таблице Товаров, результатом которого были бы Товары из текущей Группы и всех ее Подгрупп.
Читать полностью »
Когда вопрос заходит о хранении в БД гибких (заранее не известных, часто изменяемых) структур данных, разработчики обычно обращаются к «великому и ужасному» EAV-паттерну, либо к ныне модным NOSQL базам данных.
Не так давно такая задача стала и передо мной.
— EAV. Вызывает у меня стойкую неприязнь, да и сказано и написано об этом было очень много всего негативного (Кайт, Фаулер, Карвин, Горман). Главный минус в том, что при написании запросов приходится оперировать уже не реальными сущностями («Сотрудник», «Дом», «Клиент», то для чего и предназначен SQL), а объектами, орагнизованными на более низком уровне (извините за сумбур). Поэтому это был самый не желательный вариант.
— NOSQL. Поначалу очень заинтересовал этот вариант (в частности MongoDB). После продолжительного использования реляционок, первое время начинаешь испытывать чувство тотальной свободы, от которого захватывает дыхание. Хранение документов любой структуры, моментальное создание новых коллекций, запросы к ним — красота! Но после непродолжительного использования эйфория начала спадать, а проблемы обнаруживаться:
— Бедный язык запросов (ИМХО) + отсутствие джойнов;
— Отсутствие схем (хорошая статья недавно была на эту тему (и не только на эту) habrahabr.ru/post/164361/);
— Отсутствие встроенной поддержки ссылочной целостности;
— Отсутствие прибамбасов в виде хранимых процедур/функций, триггеров, представлений и многого другого.
— В моем приложении помимо данных с гибкой(изменяемой) структурой также необходимо хранить обычные статические данные — таблица пользователей, посещений, сотрудников и т.д. Работать с которыми (опять же имхо) гораздо проще и (самое главное) надежнее в обычной реляционной базе (та же самая ссылочная целостность и пр.).
При написании много-сервисной системы в корой каждый сервис должен быть многопоточен, столкнулись с проблемой использования подключения к базе данных. Сервисы разрабатываются на QT, поэтому использовали модуль QtSql для взаимодействие с БД.
В итоге у нас получилось 3 класса:
.jpeg "Восстановление битой истории Skype (main.db)")
Промучавшись в очередной раз над восстановлением побившейся базы, решил набросать краткую инструкцию, как мне удалось вернуть почти всю историю сообщений скайпа. Знатоки sqlite3 приглашаются для написания более лучших способов, чем я нащупал наугад.
Переустановил ОС Win7, установил skype (6-й), привычно скопировал всю папку профиля из старого:
%AppData%RoamingSkypeмой_профиль
в новое место.
Запускаю скайп и вдруг он виснет на автовходе. После повторного запуска вижу приглашение войти. Вхожу — все контакты на месте, а сообщений — практически нигде нет. Только в некоторых групповых чатах сохранились. Вся личная переписка, коей скопилось немало — исчезла. Проделал N(^k) попыток копировать базу данных, удаляя файлы блокировок, is-corrupt и прочие. Скайп ругается, что с базой проблемы, затем просит перезайти — после чего сообщений нет.
Погуглив, нашел хабро-посты про экспорт сообщений, угон аккаунтов и т.п. Ага, значит sqlite! Это обнадёживает.
Читать полностью »
Хочу рассказать о применении шаблона Active Record для C# на практике. Такой класс реализует извлечение и запись структуры в базу данных. Бизнес логика выносится на следующие уровни абстракции, где с таким объектом можно работать уже как с обычной структурой.
Центральный случай, который я буду рассматривать для примера — это работа со справочником Country из базы данных, который часто читается, но очень редко меняется.
Использование active record объекта в коде бизнес логики выглядит вот так:
Country russia = Country.All[“Russia”];
Сочинение на тему «какую форму хранения записей я бы выбрал для энциклопедии маршрутов городского/пригородного транспорта» в вольном стиле.
Больше всего при написании этого текста я руководствовался остатками познаний из области программирования, попутно переосмысливая для себя понятие «нормальная форма записи в базе данных».
Доброго времени суток. В своем первом Android приложении я сразу столкнулся с необходимостью работать с БД. Мне необходимо было предоставить своим пользователям стартовый набор данных(около 5000-6000 записей), с которым они смогут работать «из коробки». Было принято решение прикрепить к приложению текстовый файл с данными в виде JSON, при первом запуске распарсить их и положить в базу. О том, как делать это неправильно и как потом радоваться приросту производительности после рефакторинга, можно прочесть дальше.Читать полностью »
В последнее время термин “NoSQL” стал очень модным и популярным, активно развиваются и продвигаются всевозможные программные решения под этой вывеской. Синонимом NoSQL стали огромные объемы данных, линейная масштабируемость, кластеры, отказоустойчивость, нереляционность. Однако, мало у кого есть четкое понимание, что же такое NoSQL хранилища, как появился этот термин и какими общими характеристиками они обладают. Попробуем устранить этот пробел.
Продолжая делать упор на анализ и качество кода мы наконец добрались и до фреймворков. Работа над IDE уже продолжается, а прямо сейчас мы предлагаем попробовать: