SQLAlchemy - когда создавать дополнительные модели и отношения, а не просто хранить JSON в столбце? - PullRequest
0 голосов
/ 14 марта 2019

Я пишу каркас приложения для проекта, где каждое приложение представляет собой набор функций. Для описания этих функций (схемы параметров, схемы возврата, информация о плагине и т. Д.) Я использую синтаксис, подобный OpenAPI 3.0: https://swagger.io/specification/

Эти описания API приложения хранятся в базе данных PostgreSQL с использованием SQLAlchemy и сериализуются / десериализуются с помощью Marshmallow.

Мой вопрос в основном касается вложенных объектов, таких как объект Info: https://swagger.io/specification/#infoObject

По-моему, я мог бы сделать это одним из двух способов:

A: Просто сохраните JSON-представление объекта в столбце и самостоятельно проверьте схему этого объекта:

class AppApi(Base):
    __tablename__ = 'app_api'
    id_ = Column(UUIDType(binary=False), primary_key=True, nullable=False, default=uuid4)
    info = Column(sqlalchemy_utils.JSONType, nullable=False)

B: Создание новой таблицы для каждого вложенного объекта и использование Marshmallow для проверки его по схеме во время сериализации:

class AppApi(Base):
    __tablename__ = 'app_api'
    id_ = Column(UUIDType(binary=False), primary_key=True, nullable=False, default=uuid4)
    info = relationship("Info", cascade="all, delete-orphan", passive_deletes=True)

class ApiInfo(Base):
    __tablename__ = 'api_info'
    id_ = Column(UUIDType(binary=False), primary_key=True, nullable=False, default=uuid4)
    app_api_id = Column(sqlalchemy_utils.UUIDType(binary=False), ForeignKey('app_api.id_', ondelete='CASCADE'))
    name = Column(String(), nullable=False)
    description = Column(String(), nullable=False)
    ...etc.

Я склонен пойти на вариант А, поскольку он кажется гораздо менее сложным, но вариант Б кажется более «правильным». Вариант А дает мне больше гибкости и не требует, чтобы я делал модели для каждого отдельного объекта, но Вариант B делает более понятным то, что хранится в базе данных.

Информационный объект приложения не будет доступен независимо от остального API приложения, поэтому я не уверен, что создание отдельной таблицы для него имеет большое значение.

Какие еще соображения я должен сделать, чтобы выбрать один или другой?

1 Ответ

0 голосов
/ 14 марта 2019

Я думаю, что Б. лучше.

С этой конфигурацией вы можете получить доступ к столбцу ApiInfo быстрее (и проще).

...