Любые подсказки относительно планирования большой [закрытой] базы данных

Рисование на диаграммах ER может помочь справиться со сложностью.

Изменить: Позвольте мне добавить, что существуют также правила / рекомендации, которые помогут преобразовать диаграммы ER в реляционную схему, и есть также инструменты, которые помогут в этом процессе.

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

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

Вы можете разделить таблицы на разные диски для ускорения доступа (я предполагаю, что mySQL может это сделать). Вы можете получить высокоскоростные диски.

Может быть, вы имеете в виду большой, много столов. Это довольно обширная тема, но вы можете начать с этого:

• Определите первичный ключ для ваших таблиц
• Создайте отношения между этими таблицами, определив внешние ключи
• Создайте индексы для часто используемых полей WHERE

Некоторые разработчики которые летят мимо штанов, не делают таких вещей. Престижность для размышлений.

Visio может создавать диаграммы отношений. То же самое можно сделать с бумагой и карандашом.

Вот некоторая информация по теме моделирования данных : http://en.wikipedia.org/wiki/Data_modeling

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

Удачи!

Подумайте об управлении версиями схемы. Как вы собираетесь обрабатывать изменения схемы базы данных с течением времени? Вам нужно перенести или обновить данные? Можете ли вы выбросить данные во время разработки?

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

Нарисуйте много изображений.

Похоже, вы это уже знаете: но ассоциативные сущности ( http://en.wikipedia.org/wiki/Associative_Entities ) часто требуются для работоспособности БД.

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

Я бы начал с соглашения об именах. Я использую * _NM (для имени) и _NUM (для чисел), V_ для представлений и т. Д.

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

Лично Мне нравится использовать идентификатор для идентификаторов в каждой таблице с идентификатором (обычно это PK), а затем для отношений внешнего ключа как _ID для представления отношения. Например,

Таблица SCHOOL имеет PK идентификатора.

Таблица STUDENT имеет PK идентификатора и FK, который ссылается на таблицу SCHOOL, SCHOOL_ID.

Итак, посмотрев на таблицу учеников без каких-либо ERD, легко увидеть, что SCHOOL_ID ссылается на SCHOOL.ID, и это хорошо выглядит при чтении оператора SQL.

Что касается инструмента моделирования данных, Эрвин: http://www.ca.com/us/data-modeling.aspx

So, before I offer any advice on how best to design a large schema, I need to ask one question: Is a large schema absolutely necessary?

You asked if there are any good software methodologies for planning large systems. Indeed there are, and one of the best approaches to complex software development is SOA: Service Oriented Architecture. If you wish to educate yourself a bit on SOA best practices beyond the database level, I highly recommend looking into Thomas Erls books, notably his SOA: Principles of Service Design. I also highly recommend listening to some of Udi Dahan's lectures on service-oriented and domain-driven design and architectures. Lot of good knowledge to be had from both of these guys.

When it comes to databases, before you dive in and develop a very large, complex schema, make sure you really, really truly need it. In a service-oriented environment, the motivation is to identify distinct, unbreakable boundaries between the distinct services of the business problems you are trying to solve. Once you have identified these boundaries, you should find that there are smaller schemas that can be created within them. Sometimes this leads to data duplication, as information must be published from one service to another when it needs to cross boundaries. But the benefits of having several smaller, less complex schemas can be huge. You gain greater autonomy, portability, flexability, and maintainability than you have with a single monstrous schema.

Look into SOA, particularly how to handle databases in a service-oriented architecture. The following presentation given by Udi Dahan should also provide some very useful insight:

http://www.vimeo.com/5022174

Загрузите и создайте свою базу данных с помощью инструмента MySQL Workbench. Поможет вам создать и поддерживать базу данных.