Ne bir "yumuşak" uygulamak için en iyi yolu

4 Cevap php

Ben sadece bir "üstün" kullanıcı onayı altında modifiye edilmesi gereken bazı kayıtlar ihtiyacı LAMP bir MVC tabanlı web uygulaması üzerinde çalışıyorum. (Normal kullanıcı değişiklikleri yazabilir ama onlar sadece bu onayından sonra uygulanır olsun)

Bu, gerçekleşecek "olayları" demek zorunda hangi yalnızca bir tablo vardır:

EVENTS - id - name VARCHAR - start_date DATETIME - guest INTEGER

Bir revizyon (ve olası onayı) bu "süper" kullanıcı var yılına kadar olayların özelliklerinden biri "normal" bir kullanıcı tarafından değiştirilmiş olur her zaman, bu değişiklikleri resmi yapılmış değildir.

İlk başta ben aşağıdaki seçeneklerden olsa:

  • Id hariç, her sütun çoğaltarak, bekleyen onay değişiklik tutmak için, "isim" için name_temp söylüyorlar.
  • Yinelenen bir yapıya sahip ayrı bir tablo oluşturma ve orada tüm Onay bekleyen değişiklikleri tutun.

Daha önce bu hayata geçirdik? Bunu yapmak için en iyi / sizin yoludur ne düşünüyorsunuz? Ve ayrıca: Is there any pattern for this kind of problem?

Teşekkürler!

PD: Yeni bir onaylanan alır kadar öyleydi "eski" kaydını tutmak gerekir ..

4 Cevap

Bana "ikinci tablo" yaklaşımı için oyumu toplayalım - ikisi de diğer katılımcıların Baş ve omuzlar (onun şema zorlaştıracaktır ana tabloya "önerilen değişiklikleri" kerata girişimlerine yukarıda, onu her sorgu, vb, dediği gibi, vb.)

Eğer sırasında sadece belirli zamanlarda değiştirmek için ana tablo gerektiğinde yardımcı bir tablo tüm amaçlanan değişiklikler Yazma ve "toplu" (belirli şartları meed ise ana tabloya bunları uygulamak) bunları işleme sonra sık sık, gerçekten yararlı bir modeldir önerilen değişiklikler, örneğin, her zaman gelip, ve diğer koşullar olabilir ana tabloya yazarken çok pahalı (Çekişme veya ne olursa olsun kilit) ancak N değişiklikleri yazılı bir yazı, ya da bir değişiklik önerisini doğrulayarak daha pahalı değil, çok zaman alıcı (eğer aşırı bir durumda olarak sınıf kullanımı durumda olabilir ;-) çok yavaş gerçekten bilgisayar standartlarına göre - İkinci kategori, sizin durumunuzda bu yana doğrulama önerilen değişiklik bakmak için bir insan gerektirir.

Sadece yeni olaylar ekleyerek için bir izni konusunda ise, ben bir ilave boole sütuna, yani is_approved veya benzeri ile gitmek istiyorum.

Olası düzenlemeler vardır, ancak, bu yüzden, benim görüşüme göre, bu geçici değerini saklamak için aynı tabloda her sütun çoğaltmak için büyük bir hayır-hayır var. Sadece iki kullanıcı aynı olaya kendi değişiklikleri yayınlayacağız ne zaman ne olacağını düşünün.

Seçenek sayısı iki, yani ayrı bir tablo, daha iyi bir seçimdir. Orada her girişimi saklamak ve sadece buna göre ana tablo güncelleyebilirsiniz.

Bu yaklaşımla rollbacking değişikliklerin bile bir tür mümkündür. Sadece her bir damgası saklamak ve asla kabul düzenlemelerinizi silmek emin olun.

Neden IsApproved adında 1 fazla sütun eklemek değil mi? bool veya tinyint (1) yazın? ve sadece şimdi olayları onayladı göstermek?

Edit: Oh it's every attribute approval. Then 2nd table would be my choice named PendingEventChanges with same structure or just id+changeable properties, and on aproval "super" user would update original data and would remove etries from pending.

İlk seçim çok veritabanı normalleştirme karşı, bu nedenle gelecekte daha fazla özellik ekleyerek sorun neden olur.

Tarih veya sürüm önemli ise, onayı ile birlikte, tek bir tablo için gitmek istiyorum. Eğer mevcut birincil anahtar ile işe yarayabilir ve her revizyon artırılır olabilecek bir revizyon numarası eklersiniz. Daha sonra güncel sürümü, süresi dolmuş versiyonları ve onay sürümleri ihtiyacı olan göstermek için bir devlet alanı ekleyebilirsiniz. Devlet ve anahtar alanında güzel bir dizin size çabuk sonuç alırsınız. Bu sadece bir, iki veya birçok dışında üç alanlar ise, yukarıda önerildiği gibi, daha sonra bu onaylanmamış düzenlemeleri işlemek için belirli bir tablo daha iyi olabilir.

etiketler