SQLAlchemy — когда создавать дополнительные модели и отношения, а не просто хранить JSON в столбце?

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

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

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

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

О: Просто сохраните 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.

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

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

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


person andrewp    schedule 14.03.2019    source источник


Ответы (1)


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

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

person user2854287    schedule 14.03.2019
comment
Однако ApiInfo не будет использоваться независимо от остальной части AppApi, поэтому более быстрый доступ не будет иметь большого преимущества. Вот почему я искал любые другие причины или лучшие практики для выполнения B. - person andrewp; 14.03.2019