простая jdbc обертка
Мой предполагаемый вывод - просто возвращать значения hmin после запуска фрейма данных переменных с использованием функции и сохранения его в векторе. Как я могу сделать это?
Так как ваша функция векторизована, сделайте это:
result = hmin(H = dataframe1$H1, M = dataframe1$M1, s = dataframe1$s1) # same thing, using the with() helper function to save typing result = with(dataframe1, hmin(H = H1, M = M1, s = s1))
2 ответа
Мы записали нашу собственную обертку. Эта тема достойна статьи, но я сомневаюсь, что у меня когда-либо будет время для записи этого, таким образом, вот будут некоторые ключевые пункты:
-
мы охватили sql и не предприняли попытки скрыть его. единственная тонкая настройка должна была добавить поддержку именованных параметров. параметры важны, потому что мы не поощряем использование непрерывного sql (из соображений безопасности), и мы всегда используем PreparedStatements.
-
для управления соединениями, мы использовали Apache DBCP. Это было удобно в то время, но неясно, сколько из этого необходимо с современными реализациями JDBC (документы об этом материале недостает). DBCP также объединяет PreparedStatements.
-
мы не беспокоились отображением строки. вместо этого (для запросов) мы использовали что-то подобное dbutil's Apache ResultSetHandler, который позволяет Вам "подавать" набор результатов в метод, который может затем вывести информацию везде, где Вы хотели бы его. Это более гибко, и на самом деле не было бы трудно реализовать ResultSetHandler для отображения строки. для вставляет/обновляет, мы создали универсальный рекордный класс (в основном hashmap с некоторыми дополнительными дополнительными свойствами). самая большая проблема с отображением строки (для нас) состоит в том, что Вы застреваете, как только Вы делаете "интересный" запрос, потому что у Вас могут быть поля, которые отображаются на различные классы; потому что у Вас может быть иерархическая структура класса, но плоский набор результатов; или потому что отображение сложно и информационно-зависимо.
-
мы создали в регистрации ошибок. для обработки исключений: на запросе мы захватываем и регистрируемся, но для обновления мы захватываем, регистрируем и повторно бросаем исключения непроверенные.
-
мы оказали поддержку транзакции с помощью подхода обертки. вызывающая сторона предоставляет код, который выполняет транзакцию, и мы удостоверяемся, что транзакция правильно организована без шанса упущения закончить транзакцию и с откатом и встроенной обработкой ошибок.
-
позже, мы добавили очень упрощенную схему отношений, которая позволяет сингл, обновляют/вставляют для применения к записи и всем ее зависимостям. для хранения вещей простыми мы не использовали это на запросах, и мы конкретно решили не поддерживать, это с удаляет, потому что это более надежно для использования расположенный каскадом, удаляет.
Эта обертка успешно использовалась в двух проектах до настоящего времени. Это - конечно, легкий вес, но в эти дни все говорят, что их код легок. Что еще более важно, это повышает производительность программиста, сокращает число ошибок (и делает проблемы легче разыскать), и относительно легко проследить через в случае необходимости, потому что мы не верим в добавление большого количества слоев только для обеспечения красивой архитектуры.
Spring-JDBC является фантастическим. Полагайте, что для проекта с открытым исходным кодом как Spring вниз сторона внешней зависимости минимизирована. Можно принять самую стабильную версию Spring, который удовлетворяет требования абстракции JDBC, и Вы знаете, что будете всегда мочь изменить исходный код сами, если Вы когда-либо будете сталкиваться с проблемой - без в зависимости от третьей стороны. Можно также исследовать реализацию на любые проблемы безопасности, которые организация могла бы иметь с кодом, написанным третьей стороной.