ChartDB – Ücretsiz açık kaynak veritabanı tasarım editörü

 (chartdb.io)
2 puan yazan GN⁺ 2024-08-29 | 1 yorum | WhatsApp'ta paylaş
  • ChartDB, veritabanı şemalarını hızla görselleştiren ve ER diyagramlarıyla çalışmayı sağlayan bir DB diyagram editörü olup, ekip iş birliği ve şema migrasyonu çalışmalarına odaklanır
  • Cloud sürümü tarayıcıda çalışır ve veritabanına erişim olmadan 15 saniye içinde diyagram elde edilebildiğini öne sürer
  • Self-Hosted sürümü ücretsiz açık kaynak olarak sunulur ve veriler ile ayarları doğrudan kontrol etmesi gereken güvenlik ve özelleştirme ihtiyaçlarına uygundur
  • Tek sorgu tabanlı şema içe aktarma, yapay zeka ile ER diyagramı oluşturma, SQL DDL dışa aktarma, otomatik senkronizasyon, gerçek zamanlı iş birliği, gömülebilir dokümantasyon ve değişiklik takibi desteklenir
  • PostgreSQL, MySQL, SQL Server, SQLite, MariaDB, ClickHouse, CockroachDB, Oracle, Snowflake ve BigQuery dahil olmak üzere çeşitli ilişkisel DBMS'ler ile bulut veri ambarı tasarımlarında kullanılabilir

Tarayıcıda kullanılan DB şema diyagramları

  • ChartDB, veritabanı şemalarını anında görselleştiren ve ER diyagramları oluşturan bir araçtır
  • Ekip iş birliği ve şema migrasyonu için kullanılan bir DB diyagram editörü olarak tanıtılır
  • Başlat düğmesi ChartDB uygulamasına yönlendirir; yanında ücretsiz başlama ve kredi kartı gerekmemesi ifadeleri yer alır
  • GitHub'da ChartDB +19K stars olarak gösterilir

Cloud ve Self-Hosted seçenekleri

  • ChartDB Cloud, veritabanlarını tarayıcıda görselleştirme yaklaşımı sunar
    • Kullanım kolaylığı ve ekip erişilebilirliği için uygun olduğu belirtilir
    • Veritabanına erişim olmadan kullanılabileceği ifade edilir
    • 15 saniye içinde diyagram elde edilebildiği öne sürülür
  • Self-Hosted, ücretsiz açık kaynak bir veritabanı tasarım editörüdür
    • Veri ve ayarlar üzerinde tam kontrol sağlar
    • Güvenlik ve özelleştirme gerektiren ortamlar için uygun bir seçenektir
  • ChartDB, DB'yi “tek sorgu” ile görselleştirebildiğini açıklar

Import → Edit → Export iş akışı

  • Instant Import

    • Her veritabanı için tüm şemayı içe aktaran tek bir sorgu sunar
    • Şema içe aktarmanın 15 saniye içinde yapılabildiği belirtilir

  • Relational DBMS

    • MySQL, MariaDB, PostgreSQL, Microsoft SQL Server ve SQLite popüler DBMS'ler olarak anılır ve desteklenen hedefler arasında gösterilir

  • Export SQL

    • Diyagramlar SQL DDL betikleri olarak indirilebilir ve veritabanında çalıştırılabilir
    • Dokümantasyonda kullanılacak görseller olarak da dışa aktarılabilir

  • Examples

    • Önceden tasarlanmış örneklerle hızlı kurulum ve tasarım referansı sunar
    • Bu bölüm WIP olarak işaretlenmiştir

  • Advanced Query Editor

    • Geri al, yinele, kopyala, yapıştır ve çoğaltma özellikleri sunar
    • Tablo, konu alanı ve not eklenebilir

  • Beautiful Shares

    • Veritabanı diyagramlarının görsel önizlemeleri oluşturulup başkalarıyla paylaşılabilir

Diyagram oluşturma, paylaşma ve senkronizasyon özellikleri

  • ChartDB - AI Agent
    • Prompt'a girilen veritabanı fikirlerini düzenlenebilir, optimize edilmiş ER diyagramlarına dönüştürür
  • Instant Import
    • Tek sorguyla tüm DB şemasını içe aktarma özelliğidir
  • Export SQL
    • İstenen SQL lehçesinde DDL betikleri üretir
  • Sync Database
    • Canlı veritabanı ile diyagramı otomatik olarak senkronize eder
  • Real time collaboration
    • Ekip üyeleri davet edilerek diyagramlar gerçek zamanlı görüntülenip düzenlenebilir
  • Amazing Docs
    • Gömülebilir diyagramlar ve özelleştirilebilir, genişletilebilir dokümanlar üretir
  • Keep on track
    • Şema değişikliklerinin diff'ini ve sürüm geçmişini takip eder

Desteklenen veritabanları

  • ChartDB'nin veritabanları ve bulut veri ambarları için tasarımı desteklediği belirtilir
  • Desteklenen öğeler şunlardır
    • PostgreSQL
    • MySQL
    • SQL Server
    • SQLite
    • MariaDB
    • ClickHouse
    • CockroachDB
    • Oracle
    • Snowflake
    • BigQuery

FAQ bölümünde görülebilen operasyonel sorular

  • ChartDB'nin veritabanını değiştirip değiştirmediğine dair bir soru yer alır
  • Notion, Miro ve Confluence içine canlı ERD gömmenin mümkün olup olmadığını soran bir madde bulunur
  • ChartDB Cloud planının ücretsiz denenip denenemeyeceğini kontrol eden bir madde vardır
  • Destek alma yöntemi, diyagram ile veritabanını senkronize etme ve fatura ile kurumsal ödeme sunulup sunulmadığı da FAQ maddeleri arasındadır

İlgili okumalar

1 yorum

 
GN⁺ 2024-08-29
Hacker News yorumları

  • Proje ekiplerinin, veri modeli dahil çözümün herhangi bir yönünü açıklayan temel diyagramlar olmadan yeni uygulama geliştirmeye atladığını sık sık gördüm.
    Basit bir ER diyagramının proje dokümantasyonunda standart hâline gelmesi için ne gerektiğini bilmiyorum. İlgili araç çok, ama gerçek sahada neredeyse hiç kullanılmıyor.
    İnsanların kullanması için Microsoft’un bunu Excel ya da PowerPoint özelliği olarak eklemesi gerekiyor olabilir. Diyagramların eksiksiz olması gerekmez; bağlama uygun temel yapıyı ve ilişkileri aktarması yeterli. Gerekirse aynı veritabanı için birden çok küçük diyagram oluşturup gereksinimleri ve tasarımı belgeleyebilirsiniz.

    • Aklıma birkaç neden geliyor. Yönetim Bilişim Sistemleri (MIS) geçmişi olan kişiler genelde veritabanlarına bilgisayar bilimi (CS) geçmişlilerden daha fazla ilgi duyar ve ERD ile başlayıp daha sonra koda geçme eğilimindedir. CS tarafı ise önce kodlamaya yatkındır.
      Ayrıca UML neredeyse bir felaketti. 90’lardan sonra diyagram dillerinin temsilcisi gibi yerleşti ama veritabanı bileşenleri yoktu; sınıf diyagramlarını ERD gibi uyarlamak gerekiyordu. UML kod değildir ve UML ile kod yazmak da zor, hatta neredeyse imkânsızdır. ERD’de kod ile diyagram arasında gidip gelmek çok daha kolaydır; diğer kodlama türlerinde ise böyle değildir.
      UML’in yükselişi ve başarısızlığının, geliştiricilerin diyagram çizmemesinde büyük rol oynadığını düşünüyorum. Üstelik çoğu geliştirici için kod editörünün sol panelinde kod yapısını ağaç olarak gösteren kod gezgini yeterlidir.
    • Sistemi anlamaya veriden başlayan biri olarak katılıyorum, ama çoğunlukta değiliz gibi hissediyorum. En azından Microsoft ekosisteminde code-first yaklaşımın büyümesi kişisel olarak beni memnun etmedi.

  • Eskiden ERD hazırlamaya oldukça olumlu bakardım; 100’den fazla tablosu olan veritabanlarında bile bunu sık sık onboarding görevi olarak kullanırdım. Ama kapsamlı ERD’ler giderek daha nadir hâle geliyor ve bence bu sorun değil.
    Bakım maliyeti yüksek olduğu için değeri uzun süre kalıcı olmuyor. İyi işlenmiş bir ERD’nin olması güzel, ama şart değil.
    ERD’yi koddan üretirken dbdiagram.io veya eraser.io gibi araçlar çok kullanılıyor. ERWin, UML/ERD diyagramlarının atası sayılır ama pahalıdır.

    • Böyle şeyleri elle yapmak neredeyse hatadır. Dediğin gibi bakımı zordur. Bence her veritabanı diyagramı otomatik üretmeli ya da en azından otomatik üretim araçlarına sahip olmalı.

  • İnsanların bu tür araçları neden kullandığını merak ediyorum. Yöneticilerle konuşmak için mi kullanılıyor?
    Gerçekten soruyorum. Belki benim de kullanmam gerekir, ama neden gerekli olduğunu hâlâ bilmiyorum.

    • Karmaşıklık belirli bir eşiğe ulaşıp anlamlı hâle geldiğinde kullanmalısınız. Proje olgunlaşıp tüm veritabanı modelini kafanızda tutmuyorsanız ya da tutmak istemiyorsanız kullanmalısınız.
      Farklı sistemlerde birden çok model varsa, başkalarıyla çalışırken veritabanı modeli hakkında iletişimi kolaylaştırmak istiyorsanız, bunu herkese açık biçimde açıklamanız gerekiyorsa ya da modeli önceden planlamak istiyorsanız da gerekir.
      Burada kullanmanız gereken şey nihai diyagramdır; ille de bu belirli araç değildir.
    • Kafamdaki tasarımı düzenlemek için böyle araçlar kullandım. Kişisel olarak DBML’yi seviyorum; çünkü kaynak yönetimine koyması kolay ve editör eklentileri de var.
      https://dbml.dbdiagram.io/home/
    • Nedeni “bir resim bin kelimeye bedeldir” sözü.
      80 tablolu bir projeyi dokümantasyonsuz devraldıysanız ya da en fazla veritabanı şeması dökümünü içeren 50 sayfalık bir belge aldıysanız bunu anlarsınız.
      Temel tabloları ve ilişkileri tek bir ERD (varlık-ilişki diyagramı) üzerinde çizebilir ve şema dökümünde olduğu gibi saatler ya da günler değil, dakikalar içinde anlayabilirsiniz.
      Şema tasarımı aşamasında çeşitli ERD editörleri veya PlantUML, MermaidJS, DBML gibi metin tabanlı diyagram araçları kullanılabilir; diyagram kaynağı da kaynak yönetimine konabilir.
      Ayrıca mevcut veritabanı şemasına ilişkin ayrıntılı bir ERD’yi CI içinde üretip düzenli olarak gözden geçirirseniz, bunun özgün tasarımla uyuşup uyuşmadığını ve mevcut şemayı doğru anlayıp anlamadığınızı kontrol edebilirsiniz.
    • İş birimi tarafıyla iletişim kurmayı ve teknik kısıtları ya da veri gereksinimlerini açıklamayı çok daha kolay hâle getirir. Karmaşık projelerde birlikte tasarım yaparken de yardımcı olur ve veri gereksinimlerini nerede karşılayamadığımızı netleştirir.
    • JavaDoc gibi dokümantasyona benzer şekilde, bir şeyin nasıl çalıştığına dair daha özlü bir bakış açısı sunar.
      “Kod zaten kendini açıklıyor!” tavrından gerçekten nefret ediyorum.

  • Benzer çok hizmet görüyorum. Ama aradığım şey, doğrudan kullanabileceğim ya da script ile kontrol edebileceğim bir araç.
    Kullanım senaryom, başka bir sürecin parçası olarak elimde bulunan model açıklamasından nispeten basit bir veritabanı diyagramı üretmek. Bellekteki yapı içinde tablo adları, sütun adları ve ilişkiler var; ER benzeri bir diyagram çizmek istiyorum.
    Şu anda kendi verimle puml dosyası üretip ardından PlantUML’i çalıştırarak png veya svg oluşturma yöntemine bakıyorum.
    Araştırınca çoğunun kendi editörü olan eksiksiz veritabanı tasarım araçları olduğunu ama API sunmadığını görüyorum; bu araç ya da dbdiagram.io gibi olanlar da genellikle yalnızca çevrim içi çalışıyor, bu yüzden benim için seçenek değiller. Öneriniz varsa gerçekten minnettar olurum.

    • SchemaSpy’ı denedin mi, merak ettim.

  • Keşke bu, projeye 5 yıl önce başlarken olsaydı. Postgres kullanan full-stack bir projede veritabanı şemasını tasarlamam gerekiyordu ve bilim alanından bir uzmanla çalışıyordum.
    Diyagramı birlikte gözden geçirirken, gelecekte ortaya çıkabilecek alana özgü gereksinimlerden kaynaklanacak sorunları o uzmanın fark edebilmesi çok yardımcı oldu.
    Bu süreçte çok sayıda bire bir toplantı yaptık; diyagrama bakarak bir sonraki toplantıya kadar değiştireceklerimi not ediyordum.
    Böyle bir araç olsaydı toplantı sırasında doğrudan değişiklik yapabilir ve yinelemeleri epey azaltabilirdik. pgAdmin gibi şeyler de vardı ama teknik olmayan kişilere pek dostça görünmüyordu; bu araç sürtünmeyi azaltabilir gibi.

  • Güzel, ama bu tür araçların temel sorunu tek yönlü olmaları ve kendilerini merkezi otorite olarak konumlandırmaya çalışmaları. Oysa bu bir çizim, veritabanı değil.
    İnsanların neden kullandığını anlıyorum, ama benim böyle bir araca ihtiyacım yok.
    Bu yüzden tüm araçlar “SQL olarak dışa aktar” sunuyor ve veritabanındaki tüm değişikliklerin diyagrama yansımasını bekliyor. Ama diyagram veritabanı olmadığına göre artık iki işiniz var.

    • “Diyagram veritabanı değildir” sözü, “harita arazi değildir” sözüyle aynı.
      Diyagram bir modeldir ve model, açıkça ifade edilmiş olsun ya da yalnızca zihinde bulunsun, her zaman vardır.
      Zihindeki model yanlış olabilir; ama kimse göremediği için hatayı gösteremez. Buna kişinin kendisi de dahil.

  • DBeaver da ERD destekliyor: https://dbeaver.com/docs/dbeaver/ER-Diagrams/
    Etkileşimli ve düzenlenebilir. “Güzel” demek zor ama ürünün tamamı FOSS ve veritabanı işleri için son derece kullanışlı.

    • DBeaver’da ERD’nin istediğim gibi çalışmasını sağlamakta epey sorun yaşadım. Benim gibiler için sorun değil; çalışana kadar kurcalayabilirim.
      Ama birlikte çalıştığım bazı kişiler için öyle değildi. Genelde böyle bir şeye ihtiyaç duyduğunuz an, SQL’e pek aşina olmayan ama alan bilgisi olan ve küçük bir veritabanı kadar Excel elektronik tablosuyla gelen kişilerle tasarım üzerinde işbirliği yaptığınız andır.

  • Statik bir landing page olmasına rağmen neden bu kadar ciddi scroll takılması yaşandığını anlamıyorum.