Как люди создают повторно используемые базы данных?

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

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

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

ответ найти сладкое пятно of абстрагирование.

Шаг первый, поговорите с очень широким спектром потенциальных клиентов и узнайте их потребности, что они в настоящее время используют и что они хотят, чтобы их текущий продукт(ы) мог сделать. Потратьте на это в 10 раз больше времени, чем вам нужно прямо сейчас. Нарисуйте потенциальные GUIs на бумаге и попросите людей, которых вы интервьюируете, посмотреть на рисунки и сделать предложения. Если это вообще возможно, наймите некоторых людей в отрасли в качестве бизнес-аналитиков, чтобы помочь с этим шагом. Спросите о юридических требованиях. Некоторые отрасли имеют много юридических проблем, а другие нет. Все, что связано каким-либо образом с медицинским миром, и вам нужно будет исследовать и полностью понять требования HIPPA, например.

дизайн структуры базы данных и GUI затем получить некоторые реальные пользователи, чтобы играть с ним. Рефакторинг основан на том, что они говорят (удивительно, сколько вещей пользователи оставляют в сборе требований, о которых они не думают, пока не столкнутся с фактическим GUI).

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

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

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

в веб-модели вы также можете создать кучу модулей и выбрать, какие клиенты будут добавлять в свое пользовательское решение. Они будут платить в зависимости от количества и сложности модулей, которые они выбирают. Таким образом, клиент, который хочет только три стандартных отчета, заплатит меньше, чем клиент, который хочет все 27. Когда предлагается новая настройка, клиент платит за разработку, если предложение кажется, что это не относится к другим, но модуль сделан так, чтобы другие могли его купить. Если другие покупают его, первоначальный клиент, который попросил об изменении, может получить часть денег до тех пор, пока не будут оплачены расходы на разработку. Они также могут потребовать, чтобы что-то осталось в качестве пользовательского модуля и заплатило гораздо более высокую цену за эту работу. У нас есть некоторые клиенты, которые не хотят, чтобы их данные на серверах в том же месте, что и другие клиенты. Излишне говорить, что мы берем огромную премию за что-то в этом роде.

настройка стоит дорого и может привести к еще многим программистам. Очень сильно подумала, прежде чем идти по пути Настройки. Это действительно может быть то, что продает ваше программное решение, но оно не очень хорошо масштабируется. Это не плохо, когда у вас есть десять заказчиков, но если у вас есть пару сотен, он может выйти из под контроля очень быстро. Гораздо труднее отказаться от настройки, как только вы ее предложите, чем добавить настройку позже из стандартный набор. Часто потребность в настройке больше в организации корпоративной отчетности. Если вы можете создать интерфейс отчетов, где люди могут выбирать, какую информацию они хотят, и сохранять свои собственные пользовательские отчеты, вы можете обрабатывать большинство потребностей в настройке в вашей отрасли без необходимости полномасштабной настройки.

лучший совет, который я могу дать, - это построить наименьший общий знаменатель....

Так....Код it как проект, ориентированный на образовательные учреждения: -)

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

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

• таблица клиентов
• стол заказов
• таблица продуктов и т. д.

в вашей ситуации вы могли бы

• таблица класс
• студенты стол
• таблица рангов, etc.

этот общий формат таблицы может быть использован во множестве приложения.

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

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

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

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

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

другой трюк, который я взял недавно, который сэкономил мне много времени, - это сохранить SQL, используемый для создания базы данных в качестве скрипта. Если я хочу настроить новую базу данных, я делаю любые изменения в исходный код, а затем загружаю страницу. Например, если я хочу создать новую таблицу customer, я загружаю http://localhost/load.РНР?generate=customer.

надеюсь, что это помогает!