2010-05-12 30 views
5

Hiện tại chúng tôi đang chạy giải pháp thương mại điện tử cho một công ty du lịch và giải trí. Mỗi khi chúng tôi có bản phát hành, chúng tôi phải đưa trang web thương mại điện tử xuống khi chúng tôi cập nhật lược đồ cơ sở dữ liệu và mã truy cập dữ liệu. Chúng tôi đang sử dụng ORM được xây dựng tùy chỉnh trong đó mỗi thực thể dữ liệu chịu trách nhiệm về các hoạt động CRUD của riêng họ. Điều này được thực hiện bằng cách tạo động SQL dựa trên các thuộc tính trong thực thể dữ liệu.cách giảm thiểu thời gian ngừng ứng dụng khi cập nhật cơ sở dữ liệu và ứng dụng ORM

Ví dụ, tổ chức dữ liệu cho một địa chỉ sẽ là ...

[tableName="address"] 
public class address : dataEntity 
{ 
    [column="address1"] 
    public string address1; 
    [column="city"] 
    public string city; 
} 

Vì vậy, nếu chúng ta thêm một cột mới vào cơ sở dữ liệu, chúng ta phải cập nhật các giản đồ cơ sở dữ liệu và cũng có thể cập nhật dữ liệu thực thể.

Như bạn có thể mong đợi, những người kinh doanh không quá hài lòng về sự cố ngừng hoạt động này vì nó đặt ra một xu hướng trong dòng tiền của họ. Những người hoạt động không hài lòng vì họ phải đối phó với một thời gian áp lực cao khi cơ sở dữ liệu và các ứng dụng được nâng cấp. Các lập trình viên rất khó chịu vì họ liên tục gặp rắc rối với hệ thống kế thừa mà họ thừa kế.

Bạn có ai trong số những người thông minh không?

Trả lời

3

Câu trả lời đầu tiên rõ ràng là không sử dụng ORM. Chỉ các lập trình viên ứng dụng mới nghĩ rằng chúng tốt. Tìm hiểu SQL giống như mọi người khác :)

OK, vậy hãy quay lại thực tế. Điều gì ngăn bạn hạn chế tất cả thay đổi giản đồ chỉ là bổ sung. Sau đó, bạn có thể cập nhật lược đồ DB bất cứ lúc nào bạn thích và chỉ cài đặt ứng dụng biên dịch cho đến khi an toàn (6 giờ hoạt động tốt nhất mà tôi tìm thấy) sau khi cập nhật DB. Nếu bạn phải loại bỏ mọi thứ, hãy thực hiện các bước theo cách khác quanh - cài đặt ứng dụng mới để lại giản đồ không thay đổi, sau đó loại bỏ các bit khỏi lược đồ.

Bạn sẽ luôn có thời gian áp lực cao khi bạn triển khai các thay đổi, nhưng ít nhất bạn có thể quản lý nó tốt hơn bằng cách thực hiện điều đó dễ dàng hơn trong việc hiểu các phần. Các DBA của bạn sẽ ổn với việc cập nhật lược đồ cho ứng dụng hiện có.

Nhược điểm là bạn phải được tổ chức nhiều hơn, nhưng đó không phải là một điều xấu khi giao dịch với các máy chủ sản xuất và bạn nên được tổ chức nghiêm túc về nó hiện tại.

+2

Tôi rất không đồng ý với điều này. –

+1

giải pháp vì nó không khác gì giải pháp của bạn, chỉ tôi nói chạy trong DB thay đổi với một lượng thời gian hơi lâu hơn trước khi chạy trong ứng dụng. Ngẫu nhiên, tôi làm việc với 911 trung tâm cuộc gọi, chúng tôi không thể có thời gian chết. Chúng tôi chia đôi lỗi chịu lỗi của chúng tôi, cập nhật DB, cập nhật các ứng dụng, sau đó không chạy hệ thống đang chạy trên hệ thống được cập nhật.Nếu chúng ta phải hoàn tác các ứng dụng của mình, việc chuyển đổi trở lại ứng dụng cũ trở nên dễ dàng hơn nhiều, giữ nguyên lược đồ DB mới. Chắc chắn, ORM đang làm điều này ngày càng khó khăn, nhưng đó là một vấn đề thực hiện mà chúng ta phải giải quyết. – gbjbaanb

+0

Giống như bất cứ điều gì khác, sử dụng đúng công cụ cho đúng công việc ... Đối với 'Ví dụ' ... Đọc các sản phẩm nặng có thể sử dụng các tính năng bộ nhớ đệm cấp đầu tiên và thứ hai được cung cấp trong hầu hết các ORM và không thực hiện cuộc gọi đến cơ sở dữ liệu. . Mặt khác, các ứng dụng ghi nặng có thể tìm thấy nó có ý nghĩa hơn để ghi tải (đặc biệt là các hàm phức tạp) vào cơ sở dữ liệu. – JoeGeeky

-1

Hỗ trợ kịch bản này sẽ thêm sự phức tạp đáng kể vào môi trường và/hoặc quy trình và/hoặc ứng dụng của bạn.

Bạn có thể chạy một quá trình cập nhật phức tạp nơi mã ứng dụng của bạn đủ thông minh để chạy chính xác trên cả lược đồ cũ và giản đồ mới cùng một lúc. Sau đó, bạn có thể cập nhật ứng dụng đầu tiên và lược đồ thứ hai. Bước thứ ba có thể là di chuyển bất kỳ dữ liệu nào, một lần nữa, ứng dụng phải có khả năng làm việc với. Trong trường hợp đó, bạn chỉ cần "tombstone" ứng dụng trong thời gian cần thiết để nâng cấp ứng dụng, có thể chỉ mất vài giây, tùy thuộc vào số lượng tệp và máy móc có liên quan đến việc nâng cấp.

Trong hầu hết các trường hợp, tốt nhất là để ứng dụng/môi trường/quy trình đơn giản và sống với trung tâm thành phố trong một thời gian chậm trong ngày/tuần/tháng. Khá nhiều ứng dụng cần phải được "gỡ xuống" theo thời gian để "bảo trì định kỳ thường xuyên".

Các vấn đề liên quan