Database
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> Database

Di chuyển dữ liệu

Đây là bài viết cuối cùng trong loạt bài về di cư Django của chúng tôi:

  • Phần 1:Những cuộc di cư của Django - Một đoạn mồi
  • Phần 2:Tìm hiểu sâu hơn về các cuộc di cư
  • Phần 3:Di chuyển Dữ liệu (bài viết hiện tại)
  • Video:Django 1.7 Migrations - mồi

Quay lại lần nữa.

Việc di chuyển chủ yếu là để giữ cho mô hình dữ liệu của cơ sở dữ liệu của bạn được cập nhật, nhưng cơ sở dữ liệu không chỉ là một mô hình dữ liệu. Đáng chú ý nhất, nó cũng là một bộ sưu tập dữ liệu lớn. Vì vậy, bất kỳ cuộc thảo luận nào về di chuyển cơ sở dữ liệu sẽ không hoàn chỉnh nếu không thảo luận về di chuyển dữ liệu.

Cập nhật ngày 12 tháng 2 năm 2015 :Đã thay đổi việc di chuyển dữ liệu để tra cứu mô hình từ sổ đăng ký ứng dụng.


Đã xác định di chuyển dữ liệu

Di chuyển dữ liệu được sử dụng trong một số trường hợp. Hai cái rất phổ biến là:

  1. Khi bạn muốn tải "dữ liệu hệ thống" mà ứng dụng của bạn phụ thuộc vào sự hiện diện của nó để hoạt động thành công.
  2. Khi một thay đổi đối với mô hình dữ liệu buộc bạn phải thay đổi dữ liệu hiện có.

Lưu ý rằng việc tải dữ liệu giả để thử nghiệm không có trong danh sách trên. Bạn có thể sử dụng di chuyển để làm điều đó, nhưng di chuyển thường chạy trên máy chủ sản xuất, vì vậy có thể bạn không muốn tạo một loạt dữ liệu thử nghiệm giả trên máy chủ sản xuất của mình.



Ví dụ

Tiếp tục từ Dự án Django trước đó, như một ví dụ về việc tạo một số “dữ liệu hệ thống”, hãy tạo một số giá bitcoin lịch sử. Django migrations sẽ giúp chúng ta bằng cách tạo một tệp di chuyển trống và đặt nó vào đúng vị trí nếu chúng ta nhập:

$ ./manage.py makemigrations --empty historical_data

Thao tác này sẽ tạo một tệp có tên historical_data/migrations/003_auto<date_time_stamp>.py . Hãy đổi tên thành 003_load_historical_data.py và sau đó mở nó lên. Bạn sẽ có cấu trúc mặc định giống như sau:

# encoding: utf8
from django.db import models, migrations


class Migration(migrations.Migration):

    dependencies = [
        ('historical_data', '0002_auto_20140710_0810'),
    ]

    operations = [
    ]

Bạn có thể thấy nó được tạo một cấu trúc cơ sở cho chúng tôi và thậm chí đã chèn các phần phụ thuộc vào. Điều đó hữu ích. Bây giờ để thực hiện một số di chuyển dữ liệu, hãy sử dụng RunPython hoạt động di chuyển:

# encoding: utf8
from django.db import models, migrations
from datetime import date

def load_data(apps, schema_editor):
    PriceHistory = apps.get_model("historical_data", "PriceHistory")

    PriceHistory(date=date(2013,11,29),
         price=1234.00,
         volume=354564,
         total_btc=12054375,
         ).save()
    PriceHistory(date=date(2012,11,29),
         price=12.15,
         volume=187947,
         total_btc=10504650,
         ).save()


class Migration(migrations.Migration):

    dependencies = [
        ('historical_data', '0002_auto_20140710_0810'),
    ]

    operations = [
        migrations.RunPython(load_data)
    ]

Chúng ta bắt đầu bằng cách xác định hàm load_data mà - bạn đoán nó - tải dữ liệu.

Đối với một ứng dụng thực, chúng tôi có thể muốn truy cập vào blockchain.info và lấy danh sách đầy đủ về giá lịch sử, nhưng chúng tôi chỉ đưa một vài vào đó để hiển thị cách hoạt động của quá trình di chuyển.

Khi chúng ta có hàm, chúng ta có thể gọi nó từ RunPython của chúng ta hoạt động và sau đó chức năng này sẽ được thực thi khi chúng tôi chạy ./manage.py migrate từ dòng lệnh.

Ghi lại dòng:

PriceHistory = apps.get_model("historical_data", "PriceHistory")

Khi chạy quá trình di chuyển, điều quan trọng là phải tải phiên bản PriceHistory của chúng tôi mô hình tương ứng với điểm trong quá trình di chuyển mà bạn đang ở. Khi bạn chạy di chuyển, mô hình của bạn (PriceHistory ) có thể thay đổi, ví dụ:nếu bạn thêm hoặc xóa một cột trong lần di chuyển tiếp theo. Điều này có thể khiến quá trình di chuyển dữ liệu của bạn không thành công, trừ khi bạn sử dụng dòng trên để lấy phiên bản chính xác của mô hình. Để biết thêm về điều này, vui lòng xem bình luận tại đây.

Điều này được cho là nhiều công việc hơn là chạy syncdb và để nó tải một vật cố định. Trên thực tế, việc di chuyển không tôn trọng đồ đạc - nghĩa là chúng sẽ không tự động tải chúng cho bạn như syncdb sẽ.

Điều này chủ yếu là do triết học.

Mặc dù bạn có thể sử dụng di chuyển để tải dữ liệu, nhưng chúng chủ yếu xoay quanh việc di chuyển dữ liệu và / hoặc mô hình dữ liệu. Chúng tôi đã đưa ra một ví dụ về tải dữ liệu hệ thống, chủ yếu là vì đó là một lời giải thích đơn giản về cách bạn sẽ thiết lập quá trình di chuyển dữ liệu, nhưng đôi khi, việc di chuyển dữ liệu được sử dụng cho các hành động phức tạp hơn như chuyển đổi dữ liệu của bạn để phù hợp với mô hình dữ liệu mới.

Một ví dụ có thể là nếu chúng tôi quyết định bắt đầu lưu trữ giá từ nhiều sàn giao dịch thay vì chỉ một sàn, vì vậy chúng ta có thể thêm các trường như price_gox , price_btc , v.v., sau đó chúng tôi có thể sử dụng di chuyển để di chuyển tất cả dữ liệu từ price vào cột price_btc cột.

Nói chung, khi xử lý việc di chuyển trong Django 1.7, tốt nhất bạn nên nghĩ đến việc tải dữ liệu như một bài tập riêng biệt với việc di chuyển cơ sở dữ liệu. Nếu bạn muốn tiếp tục sử dụng / tải đồ đạc, bạn có thể sử dụng lệnh như:

$ ./manage.py loaddata historical_data/fixtures/initial_data.json

Thao tác này sẽ tải dữ liệu từ vật cố định vào cơ sở dữ liệu.

Điều này không xảy ra tự động như với quá trình di chuyển dữ liệu (có thể là một điều tốt), nhưng chức năng vẫn ở đó; nó vẫn chưa bị mất, vì vậy hãy tiếp tục sử dụng các thiết bị cố định nếu bạn có nhu cầu. Sự khác biệt là bây giờ bạn tải dữ liệu với các thiết bị cố định khi bạn cần. Đây là điều cần lưu ý nếu bạn đang sử dụng đồ đạc để tải dữ liệu thử nghiệm cho các thử nghiệm đơn vị của mình.



Kết luận

Điều này cùng với hai bài viết trước bao gồm các trường hợp phổ biến nhất mà bạn sẽ gặp phải khi sử dụng di chuyển. Có rất nhiều tình huống khác và nếu bạn tò mò và thực sự muốn đi sâu vào quá trình di chuyển, thì nơi tốt nhất để đến (ngoài mã) là tài liệu chính thức.

Đây là bản cập nhật mới nhất và thực hiện khá tốt công việc giải thích cách mọi thứ hoạt động. Nếu có một tình huống phức tạp hơn mà bạn muốn xem ví dụ, vui lòng cho chúng tôi biết bằng cách bình luận bên dưới.

Hãy nhớ rằng trong trường hợp chung, bạn đang xử lý:

  1. Di chuyển giản đồ: Một thay đổi đối với cấu trúc của cơ sở dữ liệu hoặc các bảng mà không thay đổi dữ liệu. Đây là loại phổ biến nhất và Django nói chung có thể tự động tạo các di chuyển này cho bạn.

  2. Di chuyển dữ liệu: Thay đổi dữ liệu hoặc tải dữ liệu mới. Django không thể tạo những thứ này cho bạn. Chúng phải được tạo theo cách thủ công bằng RunPython di cư.

Vì vậy, hãy chọn di chuyển phù hợp với bạn, chạy makemigrations và sau đó chỉ cần đảm bảo cập nhật tệp di chuyển của bạn mỗi khi bạn cập nhật mô hình của mình — và đó là điều ít nhiều. Điều đó sẽ cho phép bạn lưu trữ các di chuyển cùng với mã của bạn trong git và đảm bảo rằng bạn có thể cập nhật cấu trúc cơ sở dữ liệu của mình mà không phải mất dữ liệu.

Chúc bạn di chuyển vui vẻ!



  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Nếu bạn đang sử dụng các chế độ xem được lập chỉ mục và MERGE, vui lòng đọc phần này!

  2. Cách thả bảng và cột bằng SQL

  3. Xuân Hội nhập là gì?

  4. Định dạng dữ liệu trong Power BI Desktop Visualizations

  5. 10 tài nguyên hữu ích cho những ai muốn biết thêm về SQL