Какой ваш любимый способ взаимодействовать с базами данных с вашего языка программирования? [закрыто]
Вы можете использовать функцию json_populate_recordset. https://www.postgresql.org/docs/11/functions-json.html Лучше всего использовать в качестве бокового и должен создать тип раньше.
postgres=# CREATE TYPE x AS (a int, b int);
CREATE TYPE
postgres=# CREATE TABLE y(id int, c json);
CREATE TABLE
postgres=# INSERT INTO y VALUES(1,'[{"a":1},{"a":2,"b":3},{"b":4}]');
INSERT 0 1
postgres=# SELECT z.* FROM y, json_populate_recordset(NULL::x, c) z;
┌───┬───┐
│ a │ b │
╞═══╪═══╡
│ 1 │ │
│ 2 │ 3 │
│ │ 4 │
└───┴───┘
(3 rows)
postgres=#
===== edit: ====
пример на вашем столе:
DROP TABLE IF EXISTS moodys_table;
BEGIN;
CREATE TABLE moodys_table ("ID" int, json_col json);
--INSERT INTO moodys_table VALUES (1, '[{"A":"foo11", "B":[{"C":"bar111", "D":"baz111"},{"C":"bar112", "D":"baz112"}],{"A":"foo12","B":[{"C":"bar121", "D":"baz121"}]}]'::json);
--missing braces in json
INSERT INTO moodys_table VALUES (1, '[{"A":"foo11", "B":[{"C":"bar111", "D":"baz111"},{"C":"bar112", "D":"baz112"}]},{"A":"foo12","B":[{"C":"bar121", "D":"baz121"}]}]'::json);
INSERT INTO moodys_table VALUES (2, '[{"A":"foo21", "B":[{"C":"bar211", "D":"baz211"}]}]'::json);
CREATE TYPE btype AS ("C" varchar, "D" varchar);
CREATE TYPE json_col_type AS ("A" text, "B" json); --btype[]);
SELECT * FROM moodys_table;
SELECT "ID", data."A", data2.*
, dense_rank() over(partition by "ID" ORDER BY "A") json_col_id
, dense_rank() over(partition by "ID", "A" ORDER BY "C", "D") b_id
--order in json array have no sense
FROM moodys_table
, json_populate_recordset(NULL::json_col_type, json_col) data
, json_populate_recordset(NULL::btype, "B") data2
;
ROLLBACK;
postgres=# \i /tmp/moodys.sql
psql:/tmp/moodys.sql:1: NOTICE: table "moodys_table" does not exist, skipping
DROP TABLE
BEGIN
CREATE TABLE
INSERT 0 1
INSERT 0 1
CREATE TYPE
CREATE TYPE
┌────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ ID │ json_col │
╞════╪═══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╡
│ 1 │ [{"A":"foo11", "B":[{"C":"bar111", "D":"baz111"},{"C":"bar112", "D":"baz112"}]},{"A":"foo12","B":[{"C":"bar121", "D":"baz121"}]}] │
│ 2 │ [{"A":"foo21", "B":[{"C":"bar211", "D":"baz211"}]}] │
└────┴───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
(2 rows)
┌────┬───────┬────────┬────────┬─────────────┬──────┐
│ ID │ A │ C │ D │ json_col_id │ b_id │
╞════╪═══════╪════════╪════════╪═════════════╪══════╡
│ 1 │ foo11 │ bar111 │ baz111 │ 1 │ 1 │
│ 1 │ foo11 │ bar112 │ baz112 │ 1 │ 2 │
│ 1 │ foo12 │ bar121 │ baz121 │ 2 │ 1 │
│ 2 │ foo21 │ bar211 │ baz211 │ 1 │ 1 │
└────┴───────┴────────┴────────┴─────────────┴──────┘
(4 rows)
ROLLBACK
15 ответов
ORM каждый раз, наименьшее я должен думать о базах данных лучше.
В C# я люблю LINQ к SQL для чего-либо нового, но мне действительно нравится использовать .netTiers + Генератор CodeSmith для получения слоя быстрых и грязных данных к случаю базы данных, если я использую C# на.NET 2.0.
Мне нравится, в спящем режиме много :)
Я знаю, что это имеет кривую обучения, но после того как Вы освоили его, это довольно хорошо.
Само собой разумеется, я не могу дождаться, чтобы достать новую Платформу Объекта в.NET 3,5 SP1 (я знаю, что это уже доступно, но я немного ленив для ввода XML :))
Мой любимый путь состоит в том, чтобы иметь объектный уровень абстракции. Идеально, это - только место, которое работает с SQL. Но на практике, объекты иногда должны делать КВ. вещи, также. Но ничто вне объекта.
До сих пор я записал такие слои сам, потому что то, что было доступно, было слишком неловким, слишком медленным или слишком большим.
Пусть любимый путь будет, должен использовать Smalltalk с Репозиторием Объекта GemStone. Почему? Никакая проблема ORM для контакта с. Я только рассмотрел бы что-то еще, если вызвано или угрожал мой работодатель.
Мы в настоящее время используем ODAC, чтобы говорить с базой данных Oracle и использовать много Пакетов Oracle (МН / SQL). n-tier система сделана через RemObjects, что означает, что наш клиент не имеет никакого SQL в нем вообще и только нуждается в способности отправить Запросы HTTP так никакая установка наверху.
Все это сделано с помощью Borland Delphi и было Уокингом в течение 2 лет в продуктивной среде.
Мы используем Delphi и Компоненты доступа к данным Oracle (ODAC) и ADO через Oracle. OleDBProvider.
ActiveRecord, который является шаблоном, зарегистрировал сначала (я думаю) в Шаблонах Fowler Архитектуры предприятия. Я полагаю, что это реализовано на языках кроме Ruby, хотя это известно как базовая технология в направляющих. Безотносительно, это - аккуратная абстракция базы данных, хотя я должен признаться, что нахожу это немного неуклюжим и в find_by_sql области. Но это может просто быть я.
Но (надевающий Сварливую шляпу Старика теперь) все ORMs в мире не являются никакой заменой для хорошего знания SQL, без которого мне действительно не нравится видеть доступ к RDBMS, разрешаемому вообще.
Мы используем смешанный подход, в зависимости от того, что подойдет для конкретной ситуации в рамках приложения:
- При чтении ценности страницы информации для отображения и чтобы пользователь обновил, мы используем, в спящем режиме
- При обработке пакета обновлений или суммировании, где большинство данных уже находится в базе данных (например, конец дня, обрабатывая) мы используем МН / SQL (и пытаемся думать в наборах),
- Когда пользователь выполняет поиск или выполняет сводный отчет, мы используем ibatis sqlmaps, чтобы создать некоторый SQL и возвратить только поля, мы интересуемся (не каждый столбец и конечно не любые ненужные дочерние строки, urggh)
- Что-либо, что действительно должно работать быстрый, мы будем использовать любые работы подхода лучше всего
Это с java/Oracle.
Я еще не вошел в мир LINQ, но я действительно полюбил классы DataTable/TableAdapter, которые Visual Studio сделала посредством набора данных XSD. Посредством нескольких перетаскиваний и щелчков после создания моей схемы базы данных, у меня теперь есть Набор данных/объект dataTable, который со строгим контролем типов, и у меня есть методы адаптера, которые используют параметрические запросы для моих хранимых процедур для всех моих операторов CRUD. Это даже создаст адаптеры таблицы запроса для некоторых из тех процедур, которые непосредственно не связываются с таблицей.
О, и если Вы еще не создали хранимые процедуры и просто имеете таблицы, мастер создаст процедуры или специальные SQL-операторы для Вас.
Это отсутствовало начиная с Visual Studio 2005 и решительно сократило мое время "структуры" с моими новыми веб-приложениями, и я могу сфокусироваться больше на бизнес-логике и логике представления.
ORM является действительно фантастическим.
Я использую Алхимию SQL при работе в рамках Python - это работает с примерно каждым DBMS, на который я натыкался.
Для легких управляемых данными приложений на MacOS X, я использую Базовые Данные, которые имеют большой инструмент моделирования данных, доступный через XCode.
Оба из них показывают, что сделанный правильно ORM превосходен. Я имел меньше успеха и удовольствия с EJB.
Я предпочитаю создавать слой модели бизнес-объекта (объекты и collecitons объектов).
Я создаю способность взаимодействовать с базой данных в каждый объект/набор (для SQL Server, я использую Систему. Данные. SqlClient). Я использовал этот шаблон для SQL Server, MySQL и Oracle.
Затем я взаимодействую с объектами из своего кода приложения.
Путем абстракции моей базы данных в объекты мой код приложения последователен независимо от базы данных бэкенда.
Мне действительно нравятся 3 + 1 уровень способ сделать вещи. Один уровень для UI, один для бизнес-логики, и для сохранения данных. Последний Вы говорите? Объекты области и интерфейсы. Это позволяет загрузить любого или два из основных уровней плюс доменный "уровень", и код должен работать.
Это полагается в большой степени на внедрение зависимости и Инверсию принципов Управления. Уровень данных/персистентности делает только две вещи. Это создает, читает, обновляет и удаляет данные и отображает его на формат объекта области.
Уровень UI делает полную противоположность. Это отображает и получает данные способом, которых пользователь может коснуться, и карты, которые производят/вводят к и от формата объекта области.
Уровень бизнес-логики просто должен знать одну вещь. Бизнес-логика. Это не заботится о том, откуда данные, и это не заботится о том, куда уровень данных помещает его. Это знает, что должно отметить учетную запись, которая была просто превышена ограничения, как физически сделать, который не является частью его задания действительно.
Сами объекты области не имеют никакой логики, они - просто контейнеры для передающих данных между уровнями. Это означает, что можно загрузить объекты области и интерфейсы, не имея необходимость думать вообще о зависимостях.
В конце дня я чувствую, что у меня есть основа довольно кода разъединения с ясно разделенными уровнями. И с некоторыми строгими интерфейсами и хорошими базовыми классами большая часть кодирования просто говорит программное обеспечение, что сделать, когда X происходит. Как это, как предполагается.
</rant>
Править: О, да. Это верно и для LINQ, SubSonic и для другого ORMs.
ActiveRecord Ruby on Rails вытирает пол всем остальным, что я видел до сих пор. LINQ похож на него, могло бы быть лучше в некоторых случаях, но ActiveRecord настолько гибок.