Statik veriler bir veritabanında mı yoksa başka bir yerde mi saklanmalıdır?


20

Şu anda bazı yazılımlar üzerinde çalışıyorum ve bununla hangi rotayı kullanacağımdan emin değilim. Bir mobil cihazda bir yerde saklamak için bazı verilerim var. Veriler asla değişmeyecek ve hiyerarşik bir ilişkiye sahip olacak ve ekranı doldurmak için kullanılacak. Bu verinin makul bir miktarı vardır.

Aşağıdaki seçeneklere sahibim:

  1. Bir dizi numaralandırma / nesne
  2. Bir XML dosyası
  3. Gömülü SQLite veritabanı

Bu özel durumda enums seçeneği en az iş olduğunu düşünüyorum, ama böyle kodda gömülü verilerden bir koku olsun.

XML dosyası bence en mantıklı.

Veritabanı daha az performans isabeti sağlamalı, ancak statik veriler için aşırıya kaçmış gibi görünmelidir.

Burada doğru tasarım yolu hangisi?

Not: 'Asla' değişimle demek istediğim nadiren değişecektir. Söz konusu veriler, bir dizi hükümet standardının bir modelidir, bu nedenle gelecekte bir noktada değişebilirler, ancak düzenli olmayacak ve standartlarımızdaki bir değişiklik iyi olarak yazılımımızı otomatik olarak güncellemeyecektir. gereksinimlerimizde bir değişikliği tetikler.


2
Bu yaklaşımların her biri arasındaki performans açısından zaman farkı nedir? Onları daha önce test ettiniz / kıyasladınız mı?
Mehdi

1
"nadiren değişiklik" - çalışma zamanında değişmesi gerekecek mi? Uygulama başlangıcında? ya da yeni bir yapı kabul edilebilir mi?

Çalışma zamanı veya başlatma sırasında asla değişmez. Yeni bir yapı kabul edilebilir
CurlyPaul

Burada net bir 'zorunluluk' olduğunu düşünmüyorum. Hem veri miktarı, niteliği hem de nasıl kullanıldığı hakkında çok az bilgi verdiniz. Yukarıdakilerin hepsini geçmişte yaptım ... hangi rotaya gittiğiniz gerçekten bağlı .
GrandmasterB

Numaralandırma / nesne olarak katıştırılmış veriye sahip olmak mutlaka yanlış değildir, en basit, en temiz ve en doğru olabilir. Her şey, verilerin gelecekte neyin değişmesine neden olabileceğine bağlıdır.
JacquesB

Yanıtlar:


18

Bunun için bir nesne kullanırdım.

Verilerin asla değişmeyeceğini söylediniz, böylece verileri uygulamada kolayca saklayabilirsiniz. Veritabanı aşırıya kaçacak ve boyutu artıracaktır.
XML dosyası da aşırı derecede aşırı olabilir ve aynı zamanda boyutu artırır.

Benim görüşüme göre en iyi seçenek bir numaralandırma veya nesne olacaktır.


2
Dürüst olmaya eğilimli olduğum şey, sevmediğim tek şey verileri kodla karıştırmak. Bazen en iyi yolun
OKB'm

Bir numaralandırma kötü bir şey değildir;) Ne tür verileriniz var?
14'te

Veriler, kategoriler ve alt kategoriler halinde düzenlenmiş bir dizi soruyu modellemektedir. Soruların yanı sıra 3 olası cevap türü ve bazı referans numaraları vardır. Proje Java'dadır, bu yüzden numaralandırma nesnesi kendini oldukça iyi bir şekilde ödünç verir. Doğru olduğunu düşünüyorum, bu uygulanması en kolay olacak ve sadece en mantıklı
CurlyPaul

11

asla değişmeyecek mi, değişecek mi? İyi bir yanıt almadan önce gerçekten cevaplamanız gereken soru budur.

Asla değişmeyen statik veriler (örn. Haftanın günleri adları) koda gitmek iyidir;

Pratik olarak hiçbir zaman değişmeyen veriler (örneğin sunucunuzun DNS adı) da koda girmek için iyidir, eğer değiştirilmesi gerekiyorsa, bir kod güncellemesi tamamdır.

Değişmeyen, ancak değişebilen veriler (örneğin, periyodik yenilemeler arasındaki zaman gecikmesi), yerel yapılandırma deposu (sqlite veya xml gibi) kolayca değiştirilebilen bir yerde muhtemelen en iyisidir.

Depolama çok az endişe vericidir - hiçbir zaman veya neredeyse hiç değişmezse, hepsini program başlangıcında okuyabilir ve program verisi olarak önbelleğe alabilirsiniz. Olası bir olayda değişmesi gerekiyorsa, uygulamanın yeniden başlatılması o kadar da önemli değildir.


Bu durumda 'asla' ne sıklıkta olacağı hakkında bazı bilgiler ekledim
CurlyPaul

@CurlyPaul onları kodda tıkadı, eğer değişirlerse muhtemelen kodu da güncellemelisiniz. Bunları yalnızca kodlama / testinizi kolaylaştırırsa sqlite / xml db'ye koyun.
gbjbaanb

"Asla değişmeyen statik veriler (örn. Haftanın günleri adları) koda gitmek iyidir" Ve o zaman bile yanlış gidebilirsiniz: uygulamanız uluslararası olana kadar bekleyin. Hafta içi isimleri hiç statik DEĞİLDİR.
Pieter B

@ PiietB ​​kafamın tepesinden sadece bir örnekti. 'Bir haftadaki gün sayısı' sizin için daha az nit seçilebilir bir örnek olabilir mi?
gbjbaanb

@gbjbaanb Diğer gezegenleri kolonileştirmeye başlayana kadar bekleyin. O zaman ne yapacaksın? / s
MiniRagnarok

5

Genellikle "asla değişmeyen" şeyler ilk değişikliktir ...
Bir veritabanı veya başka bir harici sistem (yapılandırma dosyası gibi) kullanıp kullanmadığınız, gerektiğinde kolayca ve hızlı bir şekilde erişilebildiği sürece çok az önemlidir.
Zaten bir veritabanım varsa bir veritabanı tablosu kullanma eğilimindeyim ve mantıklı (verilerin muhtemelen uygulamanın dağıtıldığı sunucuya dosya sistemi erişimi olmayan kişiler tarafından değiştirilmesi gerektiğini veya birden çok makinede çalıştığını söylüyor ve yapılandırmanın aralarında senkronize olması gerekir).
Tabii ki bir veritabanı her şeyi tutamaz. Örneğin veritabanı kimlik bilgilerinin başka bir yerde, büyük olasılıkla bir yapılandırma dosyası olarak depolanması gerekecektir.


Bu durumda 'asla' ne sıklıkta olmayacağı hakkında bazı bilgiler ekledim.
Girişiniz

M (ale) ve F (emale) cinsiyetlerini saklamak için bir "cinsiyetler" tablosu oluşturalım, değişiyorlar mı?
Martin Pfeffer

4

Herhangi bir veri için sorulması gereken soru, verilerin değişip değişmeyeceği değildir; muhtemelen bilmiyorsunuzdur ve bilseniz bile cevap muhtemelen yanıltıcı olacaktır.

Sorulması gereken soru, değiştiğinde kimin değiştirmesi gerektiğidir:

  • yazılım yazarı: koda koy
  • son kullanıcı: GUI'de bir seçenek var
  • başka biri (örneğin bir sistem entegratörü, uluslararasılaştırma hizmeti, vb.): veritabanı tablosu, dosya veya anlamlı olan şeyler (bazen bir uzantı API'sı dahil).

Salı genellikle değişmeyeceği için bir numaralandırma olmalıdır. Ama eğer deli bir diktatör Salı'nın ismini talep ettiyse ve Salı günü onun adını vermesini isterse, yazılım yazarı olarak bunu değiştirmek (veya köpekbalıklarına beslenmek) zorunda kalacaksınız.

Bu kaderden kaçınmak için tüm kullanıcılarınızın yapılandırma dosyalarını veya belirsiz veritabanı tablolarını kazmak zorunda kalmasını istemezsiniz ...


Deli diktatörler, deli proje yöneticileri, deli müşteriler ... pff.
Mehdi

Bu doğru cevap!
JacquesB

2

Verilerin gerçek dünyada temsil ettiği varlıklar değişmemesine rağmen "verilerinizin" değiştirilmesi gerekebilir. Tüm uygulamayı güncellemeden güncellenebilecek bir tür ayrı bir metin dosyası eklemenin buna değip değmeyeceğine karar vermeniz gerekir.

Örnekler:

  1. Tipografik hata / yazım hatası.
  2. Yanlışlıkla ihmal.
  3. Verileri başka bir dilde sunun.
  4. Kullanıcının kendi değişikliklerini yapması için bir yol sunun.

Diğer herhangi bir veri yapısı değişikliğinin muhtemelen uygulamanın güncellenmesi gerekecektir, bu da bir fayda sağlamaz.


1

Başlangıçta bu soru için bu cevabı stackoverflow üzerine yazdım , ancak aynı sorunun bu soru için de geçerli olduğunu düşünüyorum.

Mathias Verraes tarafından burada sorununuzu anlatan bir makale var . Modeldeki değer nesnelerini kullanıcı arayüzüne hizmet eden kavramlardan ayırmaktan bahsediyor.

Ülkeleri varlık veya değer nesnesi olarak modellemek isteyip istemediğiniz sorulduğunda makaleden alıntı:

Ülkeleri varlık olarak modellemenin ve onları veritabanında saklamasının özünde yanlış bir şey yoktur. Ancak çoğu durumda, bu aşırı karmaşık şeyler. Ülkeler sık ​​sık değişmiyor. Bir ülkenin adı değiştiğinde, aslında tüm pratik amaçlar için yeni bir ülkedir. Bir gün bir ülke artık mevcut değilse, tüm adresleri değiştiremezsiniz, çünkü muhtemelen ülke iki ülkeye ayrılmıştır.

Yeni bir kavram sunmak için farklı bir yaklaşım önerdi AvailableCountry:

Bu kullanılabilir ülkeler bir veritabanındaki varlıklar, bir JSON'daki kayıtlar veya hatta kodunuzdaki sabit kodlu bir liste olabilir. (Bu, işletmenin bir kullanıcı arayüzü aracılığıyla bunlara kolay erişim isteyip istemediğine bağlıdır.)

<?php

final class Country
{
    private $countryCode;

    public function __construct($countryCode)
    {
        $this->countryCode = $countryCode;
    }

    public function __toString()
    {
        return $this->countryCode;
    }
}

final class AvailableCountry
{
    private $country;
    private $name;

    public function __construct(Country $country, $name)
    {
        $this->country = $country;
        $this->name = $name;
    }

    /** @return Country */
    public function getCountry()
    {
        return $this->country;
    }

    public function getName()
    {
        return $this->name;
    }

}

final class AvailableCountryRepository
{
    /** @return AvailableCountry[] */
    public function findAll()
    {
        return [
            'BE' => new AvailableCountry(new Country('BE'), 'Belgium'),
            'FR' => new AvailableCountry(new Country('FR'), 'France'),
            //...
        ];
    }

    /** @return AvailableCountry */
    public function findByCountry(Country $country)
    {
        return $this->findAll()[(string) $country];
    }
}

Bu yüzden tabloları değer nesneleri ve varlıkları olarak modellemek olan 3. bir çözüm var gibi görünüyor.

BTW makaleyle ilgili bazı ciddi tartışmalar için yorum bölümünü kontrol ettiğinizden emin olun .


-1

Düşünülmesi gereken şeyler:

  • Veriler ne kadar statik? Asla değişmezse, nesnede yaşaması gerektiğinden. Verileri değiştirmek için yeniden derlemeniz ve yeniden konuşlandırmanız gerekebilir. Küçük bir değişiklik için yeniden dağıtım yapmaktan memnun musunuz?

  • Bu bir web uygulamasıysa ve web.config dosyasının bir parçasıysa, bu verilerde değişiklik yaptığınızda uygulamanın yeniden başlatılmasından memnun musunuz?

  • Veritabanına koyarsanız, bunu her zaman istemci tarafında (masaüstü uygulaması) veya sunucu tarafında (hizmet veya web sitesi) önbelleğe alabilirsiniz. Veritabanı IMO için iyi bir çözüm olabilir.


Verilerin askerler tarafından ne kadar statik olarak sağlandığına dair açıklama: "Çalışma zamanı veya başlatma sırasında asla değişmeyecek. Yeni bir yapı kabul edilebilir", bunun hesabına verilen cevabı düzenlemeyi düşünün
gnat
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.