Как легко создать таблицу/схему DB?

Question

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

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

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

Answer 1

Проектирование баз данных трудно ...

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

Тогда вам нужно принять решение о нормализации v. Insane номера JOINs для доступа к вашим данным. Необходимо учитывать такие вопросы, как «сколько логики я использую в триггерах, хранимых процедурах, в коде приложения и т. д.».

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

Я бы пойти на простой (почти) нормированной конструкции:

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 и по имени, если вы будете искать по имени.

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

Answer 6

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

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

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.) 

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

Answer 7

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

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