Как люди делают базы многоразового использования, которые могут использоваться для многих продуктов?Как люди создают повторно используемые базы данных?
Например, если у нас есть база данных, предназначенная для школы ... Можно ли ее легко модифицировать, чтобы получить колледж?
Каков способ создания базы данных, которая может использоваться как продукт, чтобы дать решение для многих клиентов с кодировкой только один раз?
Thanks
Приложению, например, для учета требований потребуется довольно сложная модель данных. У разных видов школ будут разные требования. Университет может позволить вам добавлять или отклонять курсы, но, как правило, в начальной школе нет. Университет должен планировать курсы в комнаты, тогда как начальная школа должна ставить учащихся в классы и разделять классы на классные комнаты на основе свободного места и учителей.
Ваш дизайн должен учитывать все требования, которые он должен решить, а затем реализовать их. Чем больше вы делаете программу, тем сложнее ее удовлетворить. В этом вопросе говорится: «Напишите код один раз». Если вы хотите написать одну программу, которая решает все потребности школы, ей понадобятся сотни функций; в некоторых случаях в некоторых школах требуется другая функция из другой школы; например, некоторым школам необходимо будет принудить одного учителя к предмету или классу, в то время как в другой школе могут потребоваться несколько учителей. Чем больше требований вы ожидаете встретить, тем сложнее становится приложение.
В промышленности большие приложения, как правило, написаны так, что они могут быть расширены; предусмотрен основной набор функциональных возможностей, но приложение предназначено для изменения и настройки для конкретного клиента. Это упрощает разработку, потому что вам не нужно предвидеть каждую потребность; на самом деле вам не нужно будет предвидеть многие потребности, пока у вас не будет клиента с этими потребностями. Но с «настройкой» вы не пишете код только один раз.
Важнейшим шагом является создание модели данных, которая достаточно гибкая, чтобы продлить ее позже, но не настолько гибка, что ее невозможно разработать. Самая сложная часть, как правило, правильна. Например, вы можете сказать, что в классе есть один учитель. Затем, когда выясняется, что класс нуждается в двух преподавателях, вам нужно переписать много кода и исправить множество данных. Эти изменения являются раздражающими и трудоемкими. Однако, в конце концов, вы всегда можете исправить ошибки, учитывая достаточное время программиста.
Для этого нет простой серебряной пули. Вам просто нужно сохранить общую структуру базы данных достаточно, но старайтесь избегать чрезмерного обобщения, поскольку обычно это приводит к кошмарам в обслуживании и других неприятных ловушках.
С опытом, вы начнете ценить идеальный баланс между обобщенными и специализированными. Это ключ к понятному и многоразовому дизайну кода/базы данных.
лучший совет, который я могу дать, чтобы построить к наименьшему общему знаменателю ....
Так .... код это как проект, направленных на образовательные учреждения :-)
тратить времени на обдумывание о типе данных, которые вы хотите сохранить, отвлечь его, чтобы сделать его расширяемым, а затем создать свою базу данных соответственно. Я не знаю, сможете ли вы получить полное повторное использование, как вы могли бы из кода, но вы можете создать структуру базы данных (где вам все равно придется модифицировать отдельные компоненты), которая может использоваться повторно, если вы планируете заранее.
Ответ: найти sweet spot из abstraction.
lol @ linking 'sweet spot' – mpen
Для ESL folk для тех, кто может найти термин нечетный –
Это зависит от ваших потребностей. Например, много много баз данных для бизнеса на основе продуктов используют формат, который включает в себя:
В вашей ситуации вы могли бы есть
Этот общий формат таблицы может быть повторно использована во многих приложениях.
Это все в дизайне. Во многих случаях (если не в большинстве) для баз данных потребуется определенный уровень индивидуальной настройки; но обобщенные базы данных могут обеспечить базовый уровень функциональности. Возможно создать что-то общее, достаточное для удовлетворения многих основных потребностей; но проблема заключается в том, что общность дизайна, как правило, приводит к высокой сложности. Например, вы можете сконфигурировать вашу базу данных для управления данными для большого набора потенциальных потребностей пользователей; но, как правило, лучше всего настроить схему на индивидуальные потребности учреждения.
Существуют значительные компромиссы, связанные с проектированием для ситуации повторного использования; обычно они требуют времени и сложности; то есть, легче создать что-то, что НЕ повторно используется; и, как правило, дополнительное количество времени, затраченное на создание общего дизайна и его использование, не стоит усилий.
Находите правильный баланс общности и специфики в своем дизайне базы данных, чтобы приложение, которое вы строите вокруг него, решает достаточно проблем на ваших целевых рынках, которые они все будут покупать в нем.
Обычно, когда люди делают это, у них есть несколько клиентов в той же отрасли. Поэтому, если вы являетесь веб-разработчиком электронной коммерции, вы снова и снова будете запускать те же продукты, порядок, порядок данных типа таблицы. Когда это произойдет, вам нужно создать базу данных стартера.
И если вы собираетесь идти по этому маршруту, вы также должны поддерживать сценарии обновления между каждой новой версией, которую вы делаете, чтобы вы могли более легко перейти назад и обновить больше клиентов. –
Будет ли каждый пользователь использовать всю функциональность или вы пытаетесь построить один размер для всего продукта? Я всегда обнаружил, что дополнительное время, затрачиваемое на планирование и изменение базы данных в соответствии с конкретным приложением, окупается в будущем. Гораздо проще работать с краткой структурой базы данных, чем с той, где вы пытались учесть все возможности.
Если у меня есть существующая база данных, похожая или шаблон, я обычно использую инструмент моделирования базы данных, такой как this, чтобы изменить его, а затем использовать функцию генерации SQL (под загрузкой/сохранением) для создания фактической базы данных.
Еще один трюк, который я взял недавно, что сэкономил много времени, - это сохранить SQL, используемый для генерации базы данных в виде скрипта. Если я хочу создать новую базу данных, я делаю какие-либо изменения в исходном коде, а затем загружаю страницу. Например, если бы я хотел создать новую таблицу клиентов, я загружаю http://localhost/load.php?generate=customer.
Надеюсь, это поможет!
Шаг первый, поговорите с очень большим разнообразием потенциальных клиентов и узнайте их потребности, то, что они в настоящее время используют, и то, что они хотят, чтобы их текущие продукты могли делать. Потратьте 10 раз на это, как вы думаете, что вам нужно прямо сейчас. Выложите потенциальные графические интерфейсы на бумаге и попросите собеседников посмотреть на рисунки и внести предложения. Если это вообще возможно, нанять некоторых людей в отрасли в качестве бизнес-аналитиков, чтобы помочь с этим шагом. Спросите о юридических требованиях. В некоторых отраслях есть много юридических проблем, а другие нет. Все, что связано каким-либо образом с медицинским миром, и вам, например, потребуется исследование и полное понимание требований HIPPA.
Создайте структуру базы данных и графический интерфейс, а затем попросите настоящих пользователей поиграть с ней. Рефакторинг основан на том, что они говорят (удивительно, сколько вещей пользователи не учитывают при сборе требований, о которых они не думают, пока не столкнутся с фактическим графическим интерфейсом).
Подумайте о том, что необходимо для всех потенциальных клиентов и где вам может понадобиться настройка - ваши интервью должны служить вам здесь. Решите, как обрабатывать настройки. Или даже если вы позволите. Это может сильно зависеть от отрасли и того, насколько стандартными являются их методы.
Если это программная коробка, часто дизайн включает таблицу с настраиваемыми полями, которые могут быть добавлены в формы и отчеты пользователя.
В веб-решении часто каждый пользователь, нуждающийся в настройке, может иметь свою собственную базу данных, в которой хранится пользовательская информация (и центральная база данных standdown для неизученных вещей), а программисты вносят изменения на основе запросов клиентов , Если вы пройдете этот маршрут, во второй раз, когда вы выполните настройку simliar для второго клиента, подумайте, нужно ли вам реорганизовать, чтобы сделать эту новую функцию программного обеспечения доступной для всех. Нет необходимости писать 17 отчетов о пользовательских посещаемости, которые могут отличаться только одним или двумя полями, если клиент может за меньшие деньги иметь стандартный отчет.
В веб-модели вы также можете создать кучу модулей и предложить клиентам выбрать, что добавить в их собственное решение. Они будут платить в зависимости от количества и сложности модулей, которые они выбирают. Таким образом, клиент, который хочет только три стандартных отчета, будет платить меньше, чем клиент, который хочет все 27. Когда предлагается новая настройка, клиент платит за разработку, если это предложение, похоже, не сразу применяется к другим, но модуль делается так, чтобы другие могли его купить. Если другие покупают его, первоначальный клиент, который попросил об изменении, может получить часть денег до тех пор, пока не будут оплачены затраты на разработку. Они также могут потребовать, чтобы что-то оставалось как пользовательский модуль и оплачивало гораздо более высокую цену за эту работу. У нас есть несколько клиентов, которые даже не хотят, чтобы их данные были на тех же серверах в том же месте, что и другие клиенты. Излишне говорить, что мы взимаем огромную премию за то, что делали что-то подобное.
Настройка стоит дорого и может привести к необходимости использования большего количества программистов. Перед тем, как перейти на маршрут настройки, очень сильно подумайте. Это действительно может быть то, что продает ваше программное решение, но оно плохо масштабируется. Неплохо, когда у вас десять кузнецов, но когда у вас есть пара сотен, он может выйти из-под контроля очень быстро. Гораздо сложнее отменить настройку, как только вы ее предложите, чем добавить настройку позже из стандартного набора. Часто потребность в настройке больше связана с организацией корпоративной отчетности. Если вы можете создать интерфейс для отчетов, в котором люди могут выбирать, какую информацию они хотят и сохранять свои собственные отчеты, вы можете справиться с большинством потребностей в настройке в своей отрасли без необходимости полной настройки.
Это может быть правдой, если приложение в том же домене, в этом случае приложение действует как продукт для каждого ... –