Django에서 데이터베이스 뷰를 모델로 사용할 수 있습니까?

Django에서 데이터베이스 뷰를 모델로 사용할 수 있습니까?

---

내 데이터베이스에서 만든 뷰를 내 django-view의 소스로 사용하고 싶습니다.

사용자 지정 SQL을 사용하지 않고도 가능합니까?

****** 13/02/09 업데이트 ***********

많은 답변이 제안하는 것처럼 데이터베이스에서 자신의 뷰를 만든 다음 models.py에서 정의하여 API 내에서 사용할 수 있습니다.

하지만 몇 가지 경고 :

• manage.py syncdb가 더 이상 작동하지 않습니다.
• 뷰는 이름의 시작 부분에 다른 모든 모델 (테이블)과 동일한 것이 필요합니다. 예를 들어 앱이 "thing"이면 뷰 이름이 thing_ $ viewname이어야합니다.

---

Django 1.1 이후로 Options.managed 를 사용할 수 있습니다 .

이전 버전의 경우보기에 대한 Model 클래스를 쉽게 정의하고 다른보기처럼 사용할 수 있습니다. 방금 Sqlite 기반 앱을 사용하여 테스트했는데 제대로 작동하는 것 같습니다. 보기의 "기본 키"열이 'id'가 아닌 경우 기본 키 필드를 추가하고보기가 'app_classname'이 아닌 경우 메타 옵션에서보기 이름을 지정하십시오.

유일한 문제는 Django가 테이블 생성을 시도하기 때문에 "syncdb"명령이 예외를 발생 시킨다는 것입니다. models.py와 다른 별도의 Python 파일에 '뷰 모델'을 정의하여이를 방지 할 수 있습니다. 이렇게하면 Django는 앱에 대해 생성 할 모델을 결정하기 위해 models.py를 조사 할 때 이들을 보지 못하므로 테이블 생성을 시도하지 않습니다.

---

이 질문을 접하게 될 사람들을위한 업데이트입니다 (Google 또는 다른 모든 것에서) ...

현재 Django는 데이터베이스 테이블을 관리하지 않고 모델 을 정의 하는 간단한 "적절한 방법"을 가지고 있습니다 .

Options.managed

기본값은입니다 True. 즉, Django는 적절한 데이터베이스 테이블을 syncdb만들고 reset관리 명령의 일부로 제거합니다 . 즉, Django 는 데이터베이스 테이블의 수명주기를 관리 합니다.

인 False경우이 모델에 대해 데이터베이스 테이블 생성 또는 삭제 작업이 수행되지 않습니다. 이것은 모델이 다른 방법으로 생성 된 기존 테이블 또는 데이터베이스 뷰를 나타내는 경우에 유용합니다. 이것은 인 경우 유일한 차이점 managed입니다 False. 모델 처리의 다른 모든 측면은 정상과 완전히 동일합니다.

---

postgres 9.4 및 django 1.8의 뷰를 사용하여 모델을 구현했습니다.

다음과 같은 사용자 지정 마이그레이션 클래스를 만들었습니다.

# -*- coding: utf-8 -*-
from __future__ import unicode_literals

from django.db import migrations


class Migration(migrations.Migration):

    dependencies = [
        ('myapp', '0002_previousdependency'),
    ]

    sql = """
    create VIEW myapp_myview as
     select your view here
    """

    operations = [
        migrations.RunSQL("drop view if exists myapp_myview;"),
        migrations.RunSQL(sql)
    ]

평소처럼 모델을 썼습니다. 내 목적을 위해 작동합니다.

주 -makemigrations를 실행할 때 모델에 대한 새 마이그레이션 파일이 생성되었으며 수동으로 삭제했습니다.

전체 공개-jsonb 데이터 유형에서 파생 된보기를 사용하고 ON UPDATE INSTEAD 규칙을 작성하지 않았기 때문에 내보기는 읽기 전용입니다.

---

Django의 단일 데이터베이스 제한을 해결하기 위해 MySQL을 사용하는 애플리케이션에서이 작업을 상당히 광범위하게 수행했습니다. 우리 애플리케이션에는 단일 MySQL 인스턴스에 두 개의 데이터베이스가 있습니다. "현재"데이터베이스의 각 테이블에 대한 뷰를 생성하는 한 이러한 방식으로 교차 데이터베이스 모델 조인을 달성 할 수 있습니다.

As far as inserts/updates into views go, with our use cases, a view is basically a "select * from [db.table];". In other words, we don't do any complex joins or filtering so insert/updates trigger from save() work just fine. If your use case requires such complex joins or extensive filtering, I suspect you won't have any problems for read-only scenarios, but may run into insert/update issues. I think there are some underlying constraints in MySQL that prevent you from updating into views that cross tables, have complex filters, etc.

Anyway, your mileage may vary if you are using a RDBMS other than MySQL, but Django doesn't really care if its sitting on top of a physical table or view. It's going to be the RDBMS that determines whether it actually functions as you expect. As a previous commenter noted, you'll likely be throwing syncdb out the window, although we successfully worked around it with a post-syncdb signal that drops the physical table created by Django and runs our "create view..." command. However, the post-syncdb signal is a bit esoteric in the way it gets triggered, so caveat emptor there as well.

EDIT: Of course by "post-syncdb signal" I mean "post-syncdb listener"

---

From Django Official Documentation, you could call the view like this:

#import library
from django.db import connection

#Create the cursor
cursor = connection.cursor()

#Write the SQL code
sql_string = 'SELECT * FROM myview'

#Execute the SQL
cursor.execute(sql_string)
result = cursor.fetchall()

Hope it helps ;-)

참고URL : https://stackoverflow.com/questions/507795/can-i-use-a-database-view-as-a-model-in-django