БАЗОВЫЙ вопрос сопоставления объектных отношений, заданный нубом

Question

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

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

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

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

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

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

Employees.GetPersonalInfo Employees.GetLittleMorePersonlInfoButMinusSalary и т. д. и т. д.

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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