Использование узлов для пользовательских данных имеет ряд дополнительных преимуществ, помимо простой функции редактирования / обновления / удаления:
- возможная категоризация с помощью таксономии
- неявное «владение» через отслеживание автора
- неявное отслеживание времени создания / модификации
- базовый контроль доступа по умолчанию, расширяемый огромным выбором модулей
- гибкая генерация запросов / распечатка / фильтрация по представлениям
- возможные специальные расширения / аннотации через поля CCK
- возможное определение рабочих процессов, действий и т.п.
- огромное количество хуков для программного перехвата / настройки почти каждого аспекта / сценария использования
- комментирование, голосование, оценка и множество других функций, предоставляемых всеми предоставленными модулями, которые работают на / с узлами ...
Учитывая все это, я бы сказал, что вам нужна очень веская причина, чтобы не использовать узлы для хранения данных в Drupal. Узлы - это просто фундаментальные строительные блоки практически для всего в экосистеме Drupal, и накладные расходы на удаление некоторых нежелательных «функций» по умолчанию кажутся довольно небольшими по сравнению с преимуществами.
Тем не менее, одна из возможных причин / аргументов для обработки данных, отдельно от системы узлов, может заключаться в том, что эти данные непосредственно направлены на аннотирование других узлов (представьте таксономию). Но так как вы можете легко ссылаться на узлы из других узлов (с множеством различных вариантов того, как это сделать), аргумент не слишком сильный.
Другим (гораздо более сильным) аргументом будет целостность данных - Drupal не очень силен (мягко говоря) в отношении нормализованного, реляционного хранения данных, ссылочной целостности, обработки транзакций и других смежных тем. . Если у вас есть требования в этом направлении, у вас может не быть иного выбора, кроме как пропустить концепцию узла и самостоятельно создать и поддерживать отдельный островок данных в системе.