CRUD olmayan yaklaşımların örnekleri var mı?

Ben programcıyım ama aynı zamanda arşivci olarak çalıştım. Arşivci olarak veri tutmakla ilgili çok şey var.

Verilerle ilgili işlemler söz konusu olduğunda meslektaşlarımla sık sık tartışıyorum. CRUD'daki U ve D'yi çok sevmiyorum. Daha sonra bir kaydı güncellemek Yeni bir kayıt eklemeyi ve eski kayda bir referans almayı tercih ederim. Bu şekilde bir değişiklik geçmişi oluşturursunuz. Ayrıca kayıtları silmeyi sevmiyorum, daha ziyade etkin değil olarak işaretliyorum.

Bunun için bir terim var mı? Temel olarak sadece veri oluşturma ve okuma? Bu yaklaşımın örnekleri var mı?

Bir kaydı silindi olarak işaretlemek, yumuşak silme olarak bilinir . Güncelleme için asla alternatif bir cümle duymadım, ama sanırım bu eski kaydı yumuşak bir şekilde silmenize ve yeni bir kayıt oluşturmanıza neden oluyor.

Unutulmamalıdır ki, bu tartışmalı bir tekniktir. Bağlantılara bakın: Con vs Pro .

Değişiklik geçmişini tutmayla ilgili sorunlardan biri, veritabanını kümelendirmesi ve boyutunu (kullanım şekillerine bağlı olarak) önemli ölçüde artırabilmesidir. Bu nedenle, denetim yolunu ayrı bir yerde saklamak ve gerçek uygulama tablolarını yalnızca ilgili verilerle doldurmak iyi bir fikir olacaktır. Dolayısıyla, uygulama tarafından her CRUD işlemi gerçekleştirildiğinde, değişiklik denetim tablolarına kaydedilir ve CRUD işlemi uygulama tablolarında gerçekleştirilir (yazılım silinmez).

Denetim izini ayrı tutmak, uygulamanızın etkileşim kurması için bozulmamış bir veri deposu sağlarken, ihtiyacınız olduğunda değişiklik geçmişini koruyor. Ayrıca, iş gereksinimlerinize bağlı olarak denetim izini ayrı ayrı arşivleyebilir veya hatta yok edebilirsiniz.

EventSourcing , aradığınız desen gibi geliyor.

Rengi takip etmek istediğimiz basit bir "araba" nesnesini kullanarak bir örnek alalım (sözde C # kodu aşağıdadır).

public class Car {
  public string Color { get; set; }
  public Car() { this.Color = "Blue"; }
}

Aracın rengini güncellediğimizde bir CRUD uygulamasıyla önceki renk kaybolacaktı.

MyCar.Color = "Red";
MyCar.Save();  // Persist the update to the database and lose the previous data

Bu bilgi kaybı bana en çok kaçınmak istediğiniz şey gibi geliyor (bu nedenle güncellemeden hoşlanmama ve CRUD modelinin bir kısmını silme).

Araç sınıfını, değişikliğini güncellerken olaylara yanıt vermek için yeniden yazacak olsaydık, şöyle görünebilir:

public class Car {
    public string Color { get; private set; } // Cannot be set from outside the class

    public void ApplyEvent(CarColorChangedEvent e) {
      this.Color = e.Color;
    }
}

Şimdi bu nesnenin rengini nasıl güncelleyeceğiz? Bir CarColorChanged etkinliği oluşturabiliriz !

var evnt = new CarColorChangedEvent("Red");
MyEventStore.save(evnt);
MyCar.ApplyEvent(evnt);

Gerçek model nesnesinde kaydetme eksikliğine dikkat edin? Çünkü modeli doğrudan sürdürmek yerine, modeli mevcut duruma getiren olayları devam ettiriyoruz. Bu olaylar değişmez olmalıdır .

Şimdi hızlıca ilerleyelim ve rengi birkaç kez daha değiştirelim:

var evnt = new CarColorChangedEvent("Green");
MyEventStore.save(evnt);
MyCar.ApplyEvent(evnt);

var evnt = new CarColorChangedEvent("Purple");
MyEventStore.save(evnt);
MyCar.ApplyEvent(evnt);

Etkinlik depolama alanımıza bakacak olsaydık (bir ilişki veritabanı, dosya tabanlı, vb. Olabilir), araç neslimizle ilgili bir dizi olay görürüz:

CarColorChangedEvent => Red
CarColorChangedEvent => Green
CarColorChangedEvent => Purple

O araba nesnesini yeniden inşa etmek istersek, bunu sadece yeni bir araba nesnesi oluşturarak ve olayları olay mağazamızdan bahsedilen nesneye uygulayarak yapabilirdik.

var MyCar = new Car();
var events = MyDatabase.SelectEventsForCar("CarIdentifierHere");
foreach(var e in events) {
  MyCar.ApplyEvent(e);
}
Console.WriteLine(MyCar.Color); // Purple

Olay akışı ile, sadece yeni bir araba nesnesi oluşturarak ve sadece istediğimiz olayları uygulayarak aracın durumunu önceki bir zaman dilimine geri alabiliriz:

var MyCar = new Car();
var event = MyDatabase.GetFirstEventForCar("CarIdentifierHere");
MyCar.ApplyEvent(e);
Console.WriteLine(MyCar.Color); // Red

Event Sourcing, gidilecek yoldur ve Greg Young'ın bu konuda ne söylediğine bir göz atmalısınız.

http://goodenoughsoftware.net/

Ayrıca bu sunuma Veritabanındaki (Etkinlik Mağazası) da bakınız. Başka videolar da bulabilirsiniz.

http://oredev.org/2012/sessions/a-deep-look-into-the-event-store

Özellikle silinmiş öğeleri arayabilmeniz gerekmediği sürece "yazılımdan siler" yanıtı için gitmezdim, ancak bunları silinmiş olarak değil, arşivlenmiş olarak düşünmelisiniz. Bence burada terminoloji oldukça önemli.

Ben de bir "sürüm tablosu" korumak istemem. Şimdiye kadar gördüğüm tüm "sürüm tabloları" (Şu anda temizlemeye çalışıyorum - hatalar nedeniyle bozuk 7 yıl veri ... ve geçmiş verilerimiz olsa bile geri almak için hiçbir yolu dahil) dahil .. çünkü bu bozuk gibi) koddaki hatalar nedeniyle bozuluyor ve sonunda geri dönüp bozulmanın bozulduğu verileri yeniden oluşturamadığınız için hala veri kaybediyorsunuz.

Olay kaynağı modelinde durum böyle değil. Kullanıcının ne yaptığını her zaman tam olarak tekrar oynatabilirsiniz. Bu, CRUD ve Etkinlik Kaynaklandırma arasındaki çok önemli farktır. Olay Kaynağı mimarisi, olayları veri nesnelerine veya etki alanı modeli nesnelerine kaydetmez, olay deposuna kaydeder. Bir olay birden fazla nesneyi kolayca etkileyebilir. Alışveriş sepetindeki her öğeyi gerçek bir siparişe dönüştürdüğünüz bir alışveriş sepeti çözümünü düşünün. Bir olay, tüm nesne nesnelerini ve sipariş nesnesine dönüştürülen alışveriş sepeti nesnelerini etkiler.

Veritabanındaki her tabloda her satırın sürümlü bir kopyasını tuttuysanız, o sürüm tablosunu korurken çılgınca yer ve performans yükünden bahsetmemek için belirli bir zaman damgasına geri sarmanın dehşetini hayal edin.

Etkinlik Kaynaklandırma ile, etkinlikleri belirli bir zamana kadar tekrarlayarak kolayca geri sarabilirsiniz. Anlık görüntüler kullanılarak hızlı ileri sarmalar yapılabilir, ancak bunların hepsi bir uygulama meselesidir.

Ama beğeneceğinizi düşündüğüm gerçek avantaj, özellikle veri kaybetmemekle ilgileniyorsanız, kodda bu verileri kaydeden bir hata bulursanız, geri dönüp verileri temizlemenize gerek olmamasıdır. (veri neredeyse hiç tamamlanmadığı için bu genellikle imkansızdır). Bunun yerine sadece hatayı düzeltin ve tüm olayları tekrarlayın. Sonra güzel doğru veri ile bir veritabanı olacak.

Hata ayıklama durumunda, kullanıcıdan ne sıklıkta size ne yaptığını söylemesini istediniz ... neden sadece yaptıklarını tekrar oynatmıyorsunuz ve koddan geçiyorsunuz! Oldukça şık ha.

Bu yardımcı olur umarım.

Tam olarak örnek değil, eski finansal sistemlerde WORM depolama alanınız vardı . Eğer "güncellemeniz" gerekiyorsa, yeni bir kayıt yazdınız ve her zaman son kayda güncel olarak başvurdunuz, ancak kaydedilmiş hiçbir verinin üzerine yazılamaz.

Birçok insan bu fikri daha sonraki sistemlere aktardı. Tanımladığınız şeyi WORM tabloları olarak adlandırdığınızı duydum, ama sadece bu çevrelerde.

Evet, kurumsal sistemlerde oldukça yaygındır, temelde iki yaklaşım vardır:

• her kaydın zaman damgasından geçerli ve geçerli olan "bi - temporal" ("sonsuza kadar" - null, "9999-12-31" veya bu kadar yüksek bir değere kadar geçerli bir tarihe sahip "geçerli" kayıt). Kayıtlar hiçbir zaman silinmez, bunun yerine "geçerlilik süresi" tarihi geçerli saate ayarlanır ve güncelleme durumunda geçerli saatten geçerli bir tarih ve sonsuza kadar geçerli olan yeni bir kayıt eklenir.
• "geçmiş tablosu" - bir kayıt her değiştiğinde, olayın bir zaman damgası olan bir geçmiş / günlük tablosuna eski kaydın bir kopyası dökülür.

Her iki yaklaşım için de ayrıntı düzeyinde büyük farklılıklar vardır. Örneğin, bir sipariş öğesindeki pencere öğelerinin miktarı değiştirilirse, tüm siparişin geçmişini mi yoksa yalnızca bir öğeyi mi saklıyorsunuz?

Genel olarak "iki-zamansal" bir çok ekstra iştir ve sadece "denetçi 31 Aralık itibariyle sipariş statüsü alır" gibi bir çok kullanım durumunuz varsa buna değer.

Pdr'nin önerdiği gibi "yumuşak siler" i kullanabilirsiniz . Güncellemelere gelince, buradaki cevabım gibi kayıtların geçmişini tutabilirsiniz: /dba/28195/save-history-editable-data-rdbms/28201#28201 OP'nin istediği yer Belirli veri türlerinin tüm sürümlerini takip edebilme.

temel olarak bu 4 şey olmadan crud tamamlanamaz. Crud, Oluşturma, Okuma, Güncelleme ve silme anlamına gelir, böylece yalnızca verileri okumaya çalıştığınızda bunun için basit bir sorgu kullanabilirsiniz, ancak bu üç şeyin tümü bir ve diğer ve basit veritabanı kavramlarına eklenir