Три потенциальных проекта db

Я рассматривал три аналогичных проекта базы данных, но не придумал очень сильных для или против любого из них.Три потенциальных проекта db

Один огромный стола для содержания
```
content: int id, enum type, int parent_id, varchar title, text body, text data 
```
Это присваивает каждую строку типа (новости, блог и т.д.), и имеет поля для общих/стандарта/для поиска данных, то любой нестандартного или тривиальные данные сохраняются как сериализованные xml в поле data.
Один стола для идентификаторов, много таблиц для содержания
```
ids: int id, enum tableName, int parent_id 
```
Это имеет один большой стол для идентификаторов, то все другие ссылок на таблицы этого идентификатора, что делает его легко иметь иерархическое содержание.
Комбинация двух выше, где основная таблица хранит всю общую информацию, но несущественные данные хранятся в соответствующей таблице.

Естественно, что легче сохранить данные последовательны все имеет свою собственную таблицу, но выше идеи сделать это гораздо проще заставить стандартизации общих полей, и делает его намного проще связать содержание с Афоризм (особенно с мечение).

Любые мысли или ссылки будут оценены.

источник

2009-10-09 whichdan

Чтение вашего вопроса дает мне очень мало понимания того, что вы пытаетесь сохранить в этой базе данных, и что вы собираетесь с ним делать. Если вы можете помочь нам понять их, мы будем в лучшем положении, чтобы помочь вам найти ответ. –

Как часто база данных будет обновляться данными? Насколько велики были бы ожидания таблиц? –

@lansinwd: Обновления будут нечастыми, поскольку в основном это будет статический контент. Если я сохраню комментарии в этой таблице, запись может быть более частым, но не в значительной степени. Что касается размера, я бы хотел изучить, как он работает по сравнению с остальными с 100 тыс. Строк, 1 м строк и 5-10 м строк или более. – whichdan

Я думаю, что идея таблицы поиска мастера с дополнительными таблицами для реального контента - лучшее решение. Drupal имеет сходную структуру с тем, что вы описали, и он оказался довольно гибким.

http://projects.contentment.org/blog/84

У Drupal есть основная база данных «узлов» в одной таблице и ссылки на специализированные таблицы при получении фактического содержимого.

Я не являюсь поклонником идеи попытаться собрать все в таблицу как XML. С течением времени это может стать производительностью и гибкостью.

источник

2009-10-09 18:12:08

Это идеальное решение, но преимущество использования XML заключается в том, что вы можете создавать новые типы контента, не создавая новые таблицы. Я думаю, что XML-хит может быть не слишком плохим. Данные считываются только тогда, когда запрашивается полная строка и записываются нечасто, поэтому она не будет слишком медленной, возможно, с двумя или тремя десятками полей max - вероятно, на практике это будет почти на полдюжины. – whichdan

Почему не просто разные таблицы для каждого типа контента? Новости, блог и т. Д. Мне кажется, что это лучший и простой в использовании вариант.

источник

2009-10-09 18:13:48 GSto

Это то, что я обычно делаю, но такие вещи, как маркировка, становятся немного сложнее, чем им нужно. – whichdan

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

источник

2009-10-09 18:47:41 Tenner

Три потенциальных проекта db

ответ

Смежные вопросы