перемещение схемы базы данных в drupal - PullRequest
2 голосов
/ 22 июня 2010

Я создаю веб-приложение, и я просто хочу знать, как думать о БД Drupal, происходящих из опыта MVC.У меня есть таблицы для представления данных людей, таких как SSN, имя, фамилия, почтовый индекс, адрес, язык, местоположение.Теперь на переднем крае я хочу создать форму, чтобы заполнить эту информацию для группы предметов (людей).Моя база данных нормализована, поэтому у почтового индекса есть своя собственная таблица (со ссылкой внешнего ключа на таблицу лиц).В таблице «персона» есть такие вещи, как «Имя», «Фамилия», «Адрес» и т. Д., А в таблице «язык» будут использоваться разные языковые сокращения (опять же, с внешним ключом, возвращаемым к таблице «Лицо»).* Я хотел бы знать, как переместить что-то подобное в схему Drupal.Я знаю, что мог бы создать свои собственные таблицы и связать их обратно с таблицей «узлов», а затем я предполагаю, что собираю свои формы, чтобы принимать пользовательский ввод ... но это ли предлагаемый способ сделать это?Я смотрел на веб-форму, но, похоже, это следует использовать для более простых форм, где база данных не нормализована и все просто хранится в одной большой таблице.Я не уверен, но я определенно хотел бы услышать, что вы, ребята, думаете ... и если бы вы могли указать мне на некоторые ресурсы, которые были бы великолепны.

Ответы [ 3 ]

3 голосов
/ 22 июня 2010

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

Вы обнаружите, что лучше справляетесь с Drupal, если выв основном делают вещи способом Drupal.И только для очень индивидуального решения, где вы делаете что-то, что не покрывается стандартными модулями Drupal.

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

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

2 голосов
/ 22 июня 2010

Похоже, вы просто храните информацию, и субъекты (люди) не будут пользователями сайта Drupal.

Использование узла и модулей CCK для этого позволило бы удалить большую часть работы по разработке. Например, каждая из ваших таблиц (например, Персона, Почтовый индекс, Язык) может быть представлена ​​типом контента с несколькими полями. Внешние ключи будут представлены ссылочными полями узла. Таким образом, тип контента Person может иметь одну или несколько ссылок на узлы типа Language.

Модуль migrate , кажется, хорошо используется ( 626-й по популярности среди 4000+ модулей , используемых как минимум в 10 различных сайтах Drupal), но он может быть проще чтобы создать свой собственный скрипт миграции, но я не знаком ни с вашей ситуацией, ни с вашим знакомством с API-интерфейсом Drupal, ни с модулем миграции.

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

1 голос
/ 22 июня 2010

Исходя из опыта MVC, вам может не понравиться то, как Drupal хранит данные в БД.

Был упомянут модуль Profile, но я обнаружил, что получаю большую гибкость с объединением Content Profile и CCK.* Я уже писал несколько сценариев миграции с Coldfusion на Drupal, и это не слишком сложно.

...