Как с легкостью спроектировать таблицу / схему БД? - PullRequest
0 голосов
/ 20 мая 2009

Существует ли простой способ решить, какие поля и индексы необходимы для каждой таблицы в приложении, которое вы разрабатываете?

Например, если это веб-приложение, которое просто позволяет людям создавать списки (любое количество списков, и пользователи могут создавать список «что делать» или «список покупок»), и пользователь может назначать других пользователей для редактирования список, и если список доступен для публичного просмотра или только определенным пользователям, как таблицы могут быть спроектированы так, чтобы он был очень точным и разрабатывался быстро? А как насчет индексов?

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

Ответы [ 7 ]

8 голосов
/ 20 мая 2009

Сложный дизайн базы данных ...

Как и во многих вещах в жизни, это серия компромиссов. Прежде всего вам необходимо решить, какую СУБД вы будете использовать (MySQL, SQL Server, Oracle, PostgreSQL, одна из «объектно-ориентированных» баз данных и т. Д.

Затем вам нужно принять решение о нормализации против безумных номеров JOIN, чтобы получить ваши данные. Необходимо решить такие вопросы, как «сколько логики я буду реализовывать в триггерах, хранимых процедурах, в коде приложения и т. Д.»

Не существует "Quick'n'Easy" способа разработки чего-либо, кроме самой тривиальной базы данных.

'Конечно, это только мой опыт. YMWV.

3 голосов
/ 20 мая 2009

этот ответ не входит в задачу полного объяснения структуры базы данных

Я обычно разбиваю свой дизайн на три части (часть 1 и 2 происходят впереди, а 3 обычно ближе к концу проекта)
1) создать таблицы на основе отношений (родитель / ребенок / и т. Д.)
2) создавать поля на основе содержимого (родитель имеет x атрибутов и т. Д.)
3) создавать индексы в зависимости от того, как вы выбираете данные из своих таблиц

1 голос
/ 20 мая 2009

Я бы постарался не запираться, если вы все еще пытаетесь понять, что работает.

Только из вашего описания вам понадобится таблица для информации ваших пользователей, а также:

tbl_lists:
    ID_list (primary key)
    UserID (foreign key to list owner)
    ListName

tbl_listItems:
    ID_listItem (primary key)
    ListID (foreign key to list)
    ItemDescription

tbl_permissions:
    ID_permission (primary key)
    ListID
    UserID (foreign key to user you're granting permission to)
    PermissionTypeID (what kind of permission)

tbl_permissionTypes:
    ID_permissionType (primary key)
    Description ("can view", "can edit", etc.)

Чем гибче вы сможете создавать вещи, тем лучше. Вы можете оптимизировать позже.

1 голос
/ 20 мая 2009

Я бы пошел на простой (почти) нормализованный дизайн:

CREATE TABLE lists (
                    listid serial, 
                    name varchar, 
                    ownerid int references users(userid)
                   )

CREATE TABLE list_items (
                         listid int references lists(listid), 
                         value varchar, 
                         date datetime
                        ) 

CREATE TABLE permissions (
                          permissionid serial, 
                          description varchar,
                         )

CREATE TABLE list_permissions (
                               listid int references lists(listid),
                               permissionid int references permissions(permissionid)
                               userid int references users(userid)
                              )
CREATE TABLE users (
                     userid serial,
                     name varchar
                   )

Какие индексы создать, будет зависеть от того, какие именно запросы используются чаще всего и как они выполняются. Например, если вы запрашиваете много по спискам и элементам list_items (вероятно), вам нужен индекс по listid и по имени, если вы будете искать по имени.

Просто несколько идей. Надеюсь, они полезны.

1 голос
/ 20 мая 2009

Я думаю, что решение субъективное. Когда мне нужно спроектировать таблицы, я смотрю на объект Java, который будет представлять эту конкретную модель данных, и оттуда иду. Вы найдете множество фреймворков (Django, CakePHP, RoR), если разработаете модель, а фреймворки создадут соответствующие таблицы.

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

1 голос
/ 20 мая 2009

Не слышал о каких-либо формальных подходах к этой проблеме, но есть практические правила. Все существительные и бизнес-объекты становятся таблицами, конечно же, нормализованными. И я думаю, что атрибуты говорят сами за себя. Я думаю?

Что касается индексов, то это просто работа с данными. Любой объединенный столбец заслуживает индекса (возможно, даже кластерного). Это очень ... зависит. Но есть закономерности. Но помимо оптимизации для объединений, многие индексы напрямую связаны с тем, как используются данные, и это не то, что может быть обеспечено эмпирическим правилом. Например, если вы просматриваете пользователей по pk, а другие по last_name, last_name заслуживает индекса.

0 голосов
/ 20 мая 2009

Если вы хотите, чтобы все было очень просто и не слишком заботились о нормализации. Вы можете создать одну большую таблицу, в которой будет храниться основной объект, на котором основано ваше веб-приложение, например ex: lists, и иметь ссылки на другие таблицы меньшего размера, например: tbl_listType, tbl_permission, tbl_list_items).

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

...