BASIC Объектно-ориентированный картографический вопрос, заданный noob

Question

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

Но учитывая, что я хотел бы использовать объекты для хранения результата запроса, это оставляет меня в дилемме:

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

Должен ли я повторно использовать существующий SQL и добавить в список выбранных столбцов дополнительные поля, которые требуются новой ситуации, так что одна и та же логика сопоставления запросов и объектов может быть повторно использована для обоих? Или я должен создать другой метод, который приводит к выполнению немного другого SQL, что приводит к заполнению только тех свойств объекта, которые были возвращены вторым запросом?

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

Но как вы справляетесь с этой ситуацией, когда производительность становится фактором? Вы создать такие методы, как

Employees.GetPersonalInfo Employees.GetLittleMorePersonlInfoButMinusSalary и т.д., и т.д. и т.п.

Или вы как-то в конечном итоге создание API, где пользователь вашего API должен указать, какие столбцы/свойства он хочет заселен/вернулся, тем самым добавив сложности и сделав ваш API менее дружественным/простым в использовании?

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

1) объект Сотрудник объект 2) Сотрудники коллекция, содержащая один объект Сотрудник для каждой строки Сотрудник возвращается 3) объект, например, EmployeeQueries, который возвращает содержит методы, такие как «GetHiredThisWeek», который возвращает коллекцию сотрудников 0 или более записей.

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

Answer 1

... стоимость добавления дополнительных столбцов на выход не имеет заметного влияния на производительность ...

справа. Я не совсем понимаю, что может возникнуть «новая ситуация», но в любом случае было бы гораздо лучше (IMO) получить все столбцы, а не запускать несколько запросов. Для получения большего количества столбцов не требуется большого количества штрафов за производительность (хотя в запросах потребуется больше оперативной памяти, но это не должно быть большой проблемой, кроме того, аппаратное обеспечение дешево).Кроме того, вы бы сэкономили немного времени на разработку.

Что касается второй части вашего вопроса, это действительно зависит от вас. В качестве примера, Rails использует более «удобный подход к работе», но это может быть не то, что вы хотите. Это просто зависит от ваших потребностей. Если вы готовы пожертвовать небольшим удобством для исполнения, непременно, пойдите для этого. Я бы.

Answer 2

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

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

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

Если вам нужна оптимизация, вы создадите метод/класс или, как бы то ни было, ваша библиотека ORM. Это должно быть исключение из правила; только делайте это, если у вас есть основания для этого.

Answer 3

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

Однако, если ваш SQL выполняет сложное объединение или возвращает большой набор строк, запросите точно и только то, что вы хотите. Здесь вы получаете два штрафа за производительность, каждый из которых обрабатывает каждый столбец каждый раз, когда он будет потреблять КПа без выгоды, а две системы СУБД имеют мешок трюков для оптимизации запросов (например, доступ только к индексу), которые могут использоваться только в том случае, если вы укажете точно какие столбцы вы хотите.

В большинстве случаев не существует проблемы повторного использования, поскольку процессы сканирования/поиска имеют тенденцию очень специфично для конкретного варианта использования.