Zend_Db_Table объединенные запросы и представление базы данных - PullRequest
3 голосов
/ 09 декабря 2011

Мне было интересно, каковы наилучшие методы и лучший способ достижения согласованности при доступе к данным вашей базы данных:

Текущая структура выглядит следующим образом

Data Access --> Business Logic --> Controller --> View

Мой уровень доступа к данным состоит из Zend_Db_Table, Zend_Db_TableRowset и Zend_Db_TableRow для каждой таблицы.

Моя бизнес-логика хранится в названной модели на основе table

Пример проблемного запроса:

Я хочу получить конкретного пользователя на основе его имени. Для этого у меня есть таблица user и таблица role (role.id в пользовательской таблице обозначается role_id).

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

У меня есть выбор (getName () используется в этом примере для упрощения, но это может быть любая обработка):

  • Создайте пользовательское объединение для таблицы ролей в пользовательской таблице, которая вернет index array, состоящий из associative array В этом случае я не могу вызвать мою getName() функцию, определенную в моем Model_DbTable_User, для построения имени (имя + отчество + фамилия). Даже если я «приведу» свой массив к Zend_Db_Table_Rowset (или к своему настраиваемому table_rowset), я не смогу получить доступ к своему пользовательскому методу класса, поскольку получаю универсальный объект Zend_Db_Table_Row.

  • Создайте пользовательское соединение, но создайте имя, используя CONCAT() в моем запросе во время выполнения, я все еще получаю массив, но имя является сборкой, поэтому мне не нужен метод getName(). Но если у меня есть конкретная логика, чтобы применить, я застрял.

  • Создайте представление, объединяющее таблицы user и role в моей базе данных, и создайте новый набор Zend_DbTable, Zend_DbTableRowset и Zend_DbTableRow. Таким образом, у меня может быть определенная логика в моем стеке базы данных.

  • ORM (пропел или учение (1 или 2)), у меня нет опыта работы с ними, мне может потребоваться дополнительная информация, чтобы сделать правильный выбор.

Моя альтернативная цель - убедиться, что у меня есть согласованность в моих структурах данных

т: Массив полностью:

array(
    array(row1), 
    array(row2)
);

объект полностью

$row = $rowset->current();
$row->field;

1 Ответ

1 голос
/ 10 декабря 2011

Создание представления должно быть выполнено независимо от того, что оно дополняет другие идеи в большей степени, чем с ними Вид будет:

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

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

...