#database #postgresql #api #design-patterns #typeorm
Вопрос:
Допустим, у меня есть простая база данных, как показано ниже:
Table 1. Car_registration_id (PK) | Owner | Registration_date Table 2. Car_serial_number (PK) | Car_model | Car_registration_id (FK) Пользователь делает запросы для получения произвольных представлений, как показано ниже (это могут быть и любые другие представления).
# This view has no identifying column View 1. Car_model | Owner # This view has at least 1 identifying column View 2. Car_registration_id | Car_serial_number | Owner | Car_model Ограничения заключаются в следующем:
- Интерфейсная часть не знает о схемах баз данных. Отправляйте запрос только через предоставленный API.
- Вся обработка остается на заднем конце.
Вопрос в том, какова стратегия/шаблон для разработки запросов вместе с конечными точками API, в которых пользователь может просто перейти к таблице представления на переднем конце, изменить любое количество ячеек (только ОБНОВИТЬ или УДАЛИТЬ), а затем отразить изменения в самой базе данных? Изменение может быть применено к разным таблицам, столбцам, строкам одновременно. В моем случае использования база данных может содержать более 10 таблиц, поэтому количество столбцов не мало.
В настоящее время я думаю о 2 подходах, но они, похоже, не работают:
- Создавайте конечные точки для всех возможных комбинаций, для запроса с информацией о столбцах или без нее. Это будет работать, но за счет экспоненциального объема кода для поддержания, поэтому нецелесообразно.
- Доставляйте идентифицирующие столбцы клиенту независимо от того, отображается он в представлении или нет (просто храните в памяти). Затем используйте всю информацию из запроса клиента для создания запросов соответственно. Однако, поскольку пользователь может изменять произвольное количество столбцов, это приводит к сложному условию/комбинации для построения запроса, поэтому это также проблема. Кроме того, как логически разделить конечные точки в этом случае использования?
Я использую TypeORM, но использовать необработанный SQL тоже нормально. Любая помощь будет признательна!
Комментарии:
1. Если я вас правильно понимаю: я создал API, который ищет «неизвестные» параметры .. Я построил 2 комплекта связи .. 1) запрашивает «серверную часть», какие столбцы в какой таблице, и возвращает JSON-объект структуры данных на внешний интерфейс. 2) Затем я динамически создаю форму поиска на основе этих полей, и 3) пользователь отправляет обратно в API параметры для «построения» запроса.
2. @Zak Это может быть неприменимо к моему варианту использования. Как и в ограничении, указанном выше, интерфейс не знает о схеме, поэтому запрос столбцов является нарушением. Схема абстрагируется с помощью объекта передачи данных. Теперь, просто давайте теоретически предположим, что интерфейсу разрешено видеть схему, какова будет стратегия эффективного/динамического построения запроса?