Pull to refresh
  • by relevance
  • by date
  • by rating

Варианты проектирования БД

SQL *
Все люди, вовлеченные в проектирование различных БД, думаю, нередко задаются вопросом о нужной структуре. На данный момент, есть два варианта хранения данных, каждый из которых, в свою очередь, имеет ряд своих недостатков.

1. Объединенное хранение

Например, есть таблица типов объектов (ObjectsTypes), таблица самих объектов (Objects) и их свойств (ObjectsFields). По желанию, можно хранить еще и типы полей-свойств, это не принципиально.
Связи между таблицами определены однозначно (объект имеет один тип (typeID) и ряд свойств, связанных с родительским объектом полем objectID), между объектами связь осуществляется и с помощью древовидной структуры (родитель ← ребенок) и путем заведения отдельной таблицы (ObjectsRelations) для сетевой структуры, в которой дочерний элемент может иметь несколько родительских.

2. Индивидуальное хранение

Если представлять эту реализацию на примере, то для хранения блогов нужна таблица Blogs с полями, относящимися к нему, таблица BlogsTopics, хранящая посты и их свойства, таблица BlogsVotes, содержащая все пользовательские голоса и т.д. Можно до бесконечности развивать этот пример — смысл такого хранения в том, что для каждого типа данных создается своя таблица (если нужно, то несколько).

Я считаю, что для индивидуальных решений, например, для системы Хабры, идеально подошел бы второй вариант, а первый можно использовать в коммерческих решениях (как, собственно, многие и делают).
Хотелось бы услышать неозвученные мной доводы в пользу каждого из методов.
Total votes 30: ↑26 and ↓4 +22
Views 9.4K
Comments 51

Евангелие от GUID

SQL *
Translation
Разбираясь с новым Visual C# 2008 (он настолько бесплатный для начинающих разработчиков, что я не удержался), нашел новое для себя слово в науке и технике — GUID.

Привожу пример интересной, как мне кажется, статьи, призывающей использовать глобально-уникальные идентификаторы во всех сферах народного хозяйства. Статья, в основном про .NET и прочий микрософт, но, думаю, будет полезна многим здесь, ибо реализации GUID есть почти во всех современных БД и языках (включая mySQL и PHP ;).

ПС: Если будет интересно, то выложу перевод второй части, где автор отвечает на комменты к первой статье.
Евангелие от GUID
Total votes 1: ↑1 and ↓0 +1
Views 46K
Comments 9

Краткий обзор движков таблиц MySQL

MySQL *
Цель этой статьи — дать краткий, очень сжатый обзор движков, для того, чтобы статьей можно было пользоваться при выборе движка на этапе проектирования \ создания \ оптимизации таблицы. Предполагается, что читатель знает суть вопроса по крайней мере поверхностно и способен сам отыскать всю дополнительную информацию (вопросы в комментах можно задавать всегда :) )
Читать дальше →
Total votes 123: ↑108 and ↓15 +93
Views 67K
Comments 73

Об одном подходе к построению БД на начальном этапе работ над web-проектом

Website development *
Sandbox
Здесь рассмотрен подход, который может облегчить начало работ над интернет-проектом, требования к которому может и определены, но некоторые, возможно существенные, детали нераскрыты. Считаю, что в целом все стартапы и проекты по началу редко когда могут быть описаны достаточно полно, чтобы было возможно построить требуемую архитектуру БД и грамотный код. На начальном этапе проектирование структуры БД, основанное на идее использования NoSQL-подобного подхода как черновика для проекта экономит силы и средства в условиях постоянно меняющихся требований. Данный подход позволяет получить быстрый результат и построить всю логическую схему проекта. Этот подход дает выигрыш в скорости и упрощает дело на самом бурном начальном этапе, если нам придется перекраивать архитектуру довольно часто и глубоко. При этом переход к классической, более-менее нормализованной базе достаточно безболезненный.
Читать дальше →
Total votes 16: ↑4 and ↓12 -8
Views 782
Comments 13

А какая разница какой Collation выбрать?

OTUS corporate blog Designing and refactoring *Microsoft SQL Server *

Статья подготовлена для студентов курса «MS SQL Server разработчик»
Хочу поделиться историей из одного из предыдущих проектов, которая иллюстрирует, что Collation нужно выбирать очень вдумчиво. И о том, что бывает, если этот параметр все-таки выбрали неверно, и какие варианты решения проблемы бывают.


Сначала небольшое введение о том, что же такое Collation. В SQL Server параметр Collation указывает серверу, как нужно сортировать и сравнивать строки. Вот, например, строки “Apple” и “apple”. Они разные или нет? Это зависит от указанного Collation. Если с регистром все более менее понятно, то что делать с примером “елка” и “ёлка”? Считать их как одинаковые или как разные? Это все тоже в Collation.


История случилась в проекте, функционал которого очень похож на DropBox или Google Диск. Он предоставляет возможность управлять своими синхронизированными папками и файлами на разных машинах, а также возможность другим пользователям иметь доступ к данной синхронизированной папке.


image

Читать дальше →
Total votes 21: ↑16 and ↓5 +11
Views 12K
Comments 5