Google Calendar için veritabanı tasarımı öğreticisi

 (kb.databasedesignbook.com)
13 puan yazan GN⁺ 2024-07-25 | 1 yorum | WhatsApp'ta paylaş
  • Google Calendar klonunun takvim özelliğini örnek alarak, tabloları doğrudan oluşturmadan önce mantıksal modeli tamamlayıp ardından SQL şemasına taşıyan bir tasarım akışı gösteriliyor
  • Temel yöntem, önce User, DayEvent, TimeEvent, Timezone gibi anchor'ları bulmak; ardından özellikler ve 1:N·M:N bağlantılarla gereksinimleri ve kardinaliteyi doğrulamak
  • Etkinlikler, tüm gün etkinlikleri ve zamana dayalı etkinlikler olarak ayrılıyor; zamana dayalı etkinliklerde başlangıç·bitiş için yerel saat ve her biri için Timezone saklanarak saat dilimi değişikliği olasılığı da ele alınıyor
  • Tekrarlayan etkinlikler; periyot, aralık, aylık tekrar yöntemi, bitiş koşulu ve hafta günü bağlantılarıyla ifade ediliyor; ekran render etme ve tekil örnekleri değiştirme için DaySlot ve TimeSlot ayrı anchor'lar olarak tutuluyor
  • Nihai fiziksel tasarımda temel ilke “anchor başına bir tablo” olsa da DayOfTheWeek için tablo oluşturulmadığından, 6 anchor tablosu ve 2 M:N bağlantı tablosu dahil toplam 8 SQL tablosu ortaya çıkıyor

Tasarım yaklaşımı: önce mantıksal modeli kurmak

  • Hedef, Google Calendar klonunun takvim işlevini temel alarak gerçeğe yakın bir projede veritabanı tablo tasarımı sürecini göstermek
  • Genel akış, önce saklanması gereken takvim verilerini açıklayan eksiksiz bir mantıksal model kurmak, ardından bu modeli fiziksel tablo yapısına taşımak
  • İlk bölüm, belirli bir veritabanına bağlı olmayan mantıksal modeli ele alıyor
    • MySQL, Postgres, geleneksel ilişkisel sunucular, NoSQL veya bulut veritabanlarından bağımsız olarak iş gereksinimleri modelleniyor
  • Son bölüm ise mantıksal modeli fiziksel tablolara dönüştürmenin bir yolunu gösteriyor
    • Gereksinimleri aşırı karmaşık olmayan sistemlerde geçerli bir tasarım yaklaşımı olarak görülebilir

Problem kapsamı: Google Calendar'ın temel takvim işlevleri

  • Hedef sistem çok kullanıcılı bir sistem ve kullanıcıyla ilgili veriler asgari düzeyde modelleniyor
  • Etkinliklerde başlık, açıklama, konum gibi özellikler olabilir; ancak en karmaşık kısım zaman ve tarih
  • Modellenen etkinlikler şu farkları içeriyor
    • Tüm gün etkinlikleri ve zamana dayalı etkinlikler
    • Tekrarlayan etkinlikler ve tekrarlamayan etkinlikler
    • Birden fazla güne yayılan tüm gün etkinlikleri
    • Saat dilimine bağlı olan ve başlangıç·bitiş zamanı farklı tarihlerde veya farklı saat dilimlerinde olabilen zamana dayalı etkinlikler
  • Tekrarlayan etkinlikler şu biçimleri kapsıyor
    • Her gün veya N günde bir tekrar
    • Haftanın belirli günlerinde haftalık tekrar ve 2 hafta veya daha uzun aralıklar
    • Her ay belirli bir tarihte ya da belirli bir haftadaki belirli bir günde tekrar
    • Her yıl tekrar
    • Sonsuza kadar, belirli bir tarihe kadar ya da belirli bir tekrar sayısına kadar tekrar
  • Tekrarlayan etkinliklerin belirli örnekleri başka bir tarih·saate taşınabilir veya silinebilir
  • Bazı etkinlikler geçmişte kaldıktan sonra bile tekrar planının kendisi değiştirilebilmeli

Gereksinimleri anchor, özellik ve bağlantılarla ifade etmek

  • Modelleme, önce anchor'ları bulmakla başlıyor
    • Anchor, User veya Event gibi sayılabilen ve veritabanına eklenebilen varlıklardır
    • “Veritabanımızda 200 User var”, “Bu düğmeye tıklandığında yeni bir DayEvent oluşturulur” gibi doğal cümlelerle ifade edilebiliyorsa anchor sayılabilir
  • Özellikler, anchor hakkında gerçek bilgiyi saklar
    • User için e-posta özelliği bulunur
    • DayEvent için ad, başlangıç tarihi ve bitiş tarihi bulunur
    • Tek tarihli etkinliklerde bile başlangıç ve bitiş tarihi aynı değer olarak saklanır; böylece çok günlük etkinliklerle aynı yapı kullanılır
  • İki anchor ilişki kurduğunda özellik yerine bağlantı kullanılır
    • “Bir DayEvent'i hangi User oluşturdu?” mantıksal modelde DayEvent özelliğine doğrudan User ID koymak değil, User ile DayEvent arasında bir bağlantı kurmaktır
    • Bağlantılar 1:N, M:N, 1:1 kardinaliteleriyle ifade edilir ve çift yönlü anlam iki cümleyle doğrulanır
  • User ile DayEvent arasında 1:N bağlantı vardır
    • Bir User birden fazla DayEvent oluşturabilir
    • Bir DayEvent tek bir User tarafından oluşturulur

Zamana dayalı etkinlikler ve Timezone yönetimi

  • Zamana dayalı etkinlikler için Timezone ve TimeEvent anchor'ları ekleniyor
  • Timezone modeli öğretici amaçla minimumda tutuluyor ve yalnızca insan tarafından okunabilir ad özelliği içeriyor
    • Örnek değer: Europe/Kyiv
    • Gerçek saat dilimi tanımlarında UTC ofseti, yaz saati uygulaması, DST başlangıç·bitişi, DST sırasında UTC ofseti, geçmiş tanımlar, etkin·kaldırılmış durumu gibi bilgiler gerekir; ancak bunlar ayrı bir konu olarak bırakılıyor
  • TimeEvent'te ad, başlangıç yerel tarih·saat ve bitiş yerel tarih·saat tutuluyor
    • Örnek değerler: 2024-01-14 12:30, 2024-01-14 13:15
  • Zaman yalnızca UTC olarak değil, kullanıcının girdiği yerel saat biçiminde saklanıyor
    • Örneğin 6 Eylül 2058'de Köln saatine göre 09:30~11:00 arasındaki bilardo oyunu için, o andaki UTC ofseti bugün bilinmeyebileceğinden kullanıcının girdiği değer aynen korunmalı
    • Sonradan yerel yasa değişirse buna göre uyarlanabilmeli
  • TimeEvent, başlangıç saat dilimi ve bitiş saat dilimi için ayrı ayrı Timezone ile 1:N bağlantıya sahip
    • Amsterdam'dan Londra'ya uçuş örneğinde olduğu gibi kalkış ve varış saatleri farklı saat dilimlerinde olabilir
    • Çoğu zamana dayalı etkinlikte başlangıç ve bitiş saat dilimi aynı olsa da, genel durumu desteklemek için her ikisi de her zaman belirtilir

Tekrarlayan tüm gün etkinliklerini modellemek

  • Tekrarlayan tüm gün etkinlikleri, DayEvent'e tekrar ile ilgili özellikler ve bağlantılar eklenerek ifade ediliyor
  • Tekrar sıklığı either/or/or türünde bir özellik olarak tutuluyor
    • Olası değerler: daily, weekly, monthly, annually
    • Değer ayarlanmamışsa etkinlik tekrarlamayan etkinlik kabul edilir
  • Tekrar aralığı yalnızca “etkinlik tekrarlıyorsa” anlamlı olan bir tamsayı özelliği
    • Örnek değer: 2
    • Her 2 günde bir, her 2 haftada bir, her 2 ayda bir gibi anlamlarda kullanılır
  • Aylık tekrar için ayrı bir seçim özelliği bulunur
    • Aynı tarihte tekrar eden same_day
    • Orijinal tarihle aynı haftadaki aynı hafta gününde tekrar eden same_weekday
  • Haftalık tekrarda belirli hafta günleri, string dizi özelliği olarak değil DayOfTheWeek anchor'ı ve M:N bağlantısı ile modelleniyor
    • DayOfTheWeek ID örnekleri: Mon, Tue, Wed, Thu, Fri, Sat, Sun
    • Bir DayEvent birden fazla DayOfTheWeek'te gerçekleşebilir ve bir DayOfTheWeek birden fazla DayEvent içerebilir
  • Tekrarın bitiş koşulu da özellik olarak tutulur
    • forever
    • until_date
    • N_repetitions
    • until_date ise ek olarak bitiş tarihi özelliği bulunur
    • N_repetitions ise tekrar sayısı özelliği bulunur

Render etme ve tekil örnek değişiklikleri için Slot

  • Tekrarlayan etkinlikler yalnızca tek bir kaynak etkinlik olarak tutulursa, belirli bir haftalık görünümde gösterilecek etkinlikleri bulan sorgular karmaşıklaşabilir
  • Ekran render etme ve tekrarlayan etkinliklerin tek tek değiştirilmesi için Slot kavramı getiriliyor
    • DaySlot, belirli bir tarihteki tüm gün etkinliği örneğini temsil eder
    • TimeSlot, belirli bir tarih ve saatteki zamana dayalı etkinlik örneğini temsil eder
  • DaySlot'ta tarih ve atlandı bilgisi tutulur
    • Belirli bir slot'un tarihi değiştirilebilir
    • Belirli bir haftadaki toplantı iptal edilirse ilgili DaySlot skipped olarak işaretlenebilir
  • DayEvent ile DaySlot arasında 1:N bağlantı bulunur
    • Bir DayEvent birden fazla DaySlot oluşturabilir
    • Bir DaySlot tek bir DayEvent'e karşılık gelir
    • Render kodunu basitleştirmek için tekrarlamayan DayEvent'ler için de her zaman DaySlot oluşturulur
  • Sonsuz tekrar eden etkinliklerde slot üretim aralığı problemi vardır
    • Doğum günü gibi her yıl sonsuza dek tekrar eden etkinliklerde, slot'lar 100 yıl gibi keyfi bir sınıra kadar üretilebilir
    • Ya da kullanıcı çok ileri bir tarihte takvim sayfası istediğinde isteğe bağlı olarak oluşturulabilir
  • Tarih hesaplamalarında dikkat gerekir
    • 29 Şubat doğum günü
    • Her ayın 31'inde gerçekleşen aylık etkinlik
    • Bu durumlarda kullanımı yasaklamak mı, bir gün öne ya da arkaya taşımak mı gerektiğine karar verilmelidir

TimeSlot ve saat dilimleri

  • Tekrarlayan zamana dayalı etkinliklerde de tüm gün etkinlikleriyle aynı yaklaşım uygulanarak TimeSlot anchor'ı kullanılıyor
  • TimeSlot, belirli bir etkinliğin belirli tarih·saat örneğine karşılık gelir ve tekrarlayan TimeEvent birden fazla TimeSlot'a bağlanır
  • TimeSlot özellikleri başlangıç yerel tarih·saat, bitiş yerel tarih·saat ve atlandı bilgisidir
  • Belirli bir TimeSlot başka bir güne taşınabileceği için başlangıç·bitiş zaman bilgileri ayrı tutulur
  • TimeSlot da başlangıç saat dilimi ve bitiş saat dilimi için ayrı ayrı Timezone ile 1:N bağlantıya sahiptir
  • TimeEvent ile TimeSlot arasında 1:N bağlantı bulunur ve tekrarlamayan TimeEvent'ler için de TimeSlot oluşturulur

Tamamlanmış mantıksal model

  • Buraya kadar tanımlanan anchor sayısı toplam 7
    • User
    • Timezone
    • DayEvent
    • TimeEvent
    • DayOfTheWeek
    • DaySlot
    • TimeSlot
  • Özellikler; User e-postası, Timezone adı, DayEvent'in adı·başlangıç tarihi·bitiş tarihi·tekrar bilgileri, TimeEvent'in adı·başlangıç·bitiş yerel saatleri, DaySlot ve TimeSlot'un gerçekleşme anı ve skipped bilgisi gibi öğelerden oluşuyor
  • Bağlantılar toplam 10 adet
    • User ile DayEvent, User ile TimeEvent
    • Timezone ile TimeEvent'in başlangıç·bitiş saat dilimleri
    • DayEvent ile DayOfTheWeek, TimeEvent ile DayOfTheWeek
    • DayEvent ile DaySlot, TimeEvent ile TimeSlot
    • Timezone ile TimeSlot'un başlangıç·bitiş saat dilimleri

SQL tablolarına dönüştürmek

  • Fiziksel tasarım öğretici amaçla anchor başına bir tablo stratejisini kullanıyor
  • Mantıksal modelde 7 anchor, 21 özellik ve 10 bağlantı var
  • Normalde anchor sayısına M:N bağlantı sayısı eklenince 9 tablo olurdu; ancak nihai tasarımda DayOfTheWeek özel ele alındığı için bunun için fiziksel tablo oluşturulmuyor
  • Nihai SQL tablolarının toplam sayısı 8
    • users
    • timezones
    • day_events
    • time_events
    • day_slots
    • time_slots
    • day_event_dows
    • time_event_dows
  • 1:N bağlantılar, N tarafındaki tabloya yabancı anahtar niteliğinde sütunlar olarak giriyor
    • day_events.user_id
    • time_events.user_id
    • time_events.start_timezone_id
    • time_events.end_timezone_id
    • day_slots.day_event_id
    • time_slots.time_event_id
    • time_slots.start_timezone_id
    • time_slots.end_timezone_id
  • M:N bağlantılar ayrı tablolar olarak oluşturuluyor
    • day_event_dows, DayEvent ile hafta gününü bağlar
    • time_event_dows, TimeEvent ile hafta gününü bağlar
  • Fiziksel tipler mantıksal tiplere karşılık gelecek şekilde seçiliyor
    • String için VARCHAR
    • Tarih için DATE
    • Yerel tarih·saat için DATETIME
    • Evet/hayır için TINYINT UNSIGNED
    • Yalnızca belirli koşullarda anlamlı olan iç içe geçmiş özellikler için NULL kabul eden tipler
  • NULL ve sentinel değerler, mantıksal modelin değil fiziksel şemanın kavramları olarak ele alınıyor

İndeksler ve atlanan özellikler

  • Örnek SQL şemasında, deneyimli veritabanı geliştiricilere göre gerekli olabilecek bazı indeksler eksik
    • Örneğin day_events.user_id için indeks gerekebilir
  • Hangi sütun ya da sütun kombinasyonlarına indeks konacağı, uygulamanın tabloları nasıl sorguladığına bağlıdır
  • İndeks konusu için Use The Index, Luke kaynağına bakılabilir
  • Mantıksal şema açıklanırken bazı özellikler benzer desenlere sahip oldukları için atlanmış
    • Kullanıcı adı
    • Kullanıcı parola özeti
    • Etkinlik konumu
    • Davetliler listesi
  • Atlanan veri öğeleri de aynı yöntemle mantıksal model tablosuna eklenip ardından SQL şemasına yansıtılabilir

Tüm süreç

  • İş problemini anlatan serbest biçimli metinle başlanır
  • Anchor listesi çıkarılır
  • Özellik listesi yazılır ve özelliklerin anlamı soru biçiminde açıkça belirtilir
  • Bağlantı listesi yazılır ve kardinalitenin doğru olup olmadığı cümlelerle kontrol edilir
  • Gerekirse mantıksal modelden hareketle grafiksel şema oluşturulur
  • Fiziksel model; tablo adları, sütun adları ve fiziksel veri tipleri doldurularak hazırlanır
  • Önceki adımlardaki bilgiler kullanılarak CREATE TABLE ifadeleriyle SQL şeması yazılır
  • Şema veritabanı sunucusuna gönderilir, yazım hataları düzeltilir ve yeniden gönderilir
  • Mantıksal model ekiple paylaşılır

İlgili okumalar

1 yorum

 
GN⁺ 2024-07-25
Hacker News yorumları

  • Takvimimdeki rastgele bir etkinliği iCalendar olarak serileştirince yaklaşık 740 bayt ediyor; sabah 9’dan akşam 5’e kadar her 15 dakikada bir etkinlik olan aşırı yoğun bir takvimde bile tüm yıl 11.680 öğe, yalnızca yaklaşık 8 MB tutuyor
    Bu yüzden şema tasarlamak yerine, takvimi doğrudan sıralı tarama ile uygulamanın çok daha iyi olabileceği bir problem gibi görünüyor. iCalendar ayrıştırıcısını optimize edip dökümü alınmış etkinlik aralığını GB/s düzeyinde iş hacmiyle taratabilirseniz, yukarıdaki en kötü senaryo bile tek haneli milisaniyeler içinde taranabilir
    Ayrıştırıcı optimizasyonu, kötü bir veri modelinin birçok kullanıcıya yayıldıktan sonra değiştirilmesi veya genişletilmesine kıyasla bir kez çözülmesi gereken çok daha basit bir problem; zaten yeni veri modelinin ilk işinin de muhtemelen iCalendar içe/dışa aktarma olması bekleneceğinden, oldukça iyi bir uzlaşma gibi görünüyor

    • O zaman SQL’deki BETWEEN ... AND ... gibi aralık aramasını yeniden yapmak gerekmez mi? Kullanıcı 1, 2, 3’ün etkinliklerini bulmak da aynı şekilde
      Gerçek bir uygulamada kullanıcı hesapları gibi şeyler muhtemelen zaten ilişkisel veritabanında olur; birden dizindeki etkinlikleri tarayıp sonra bu sonuçları veritabanı kayıtlarıyla ilişkilendirmek gerekir
      Belirli bir uygulama için doğru olabilir, ama veritabanlarının gerçekten iyi yaptığı belirli işler var ve bu yüzden iyi bir tercih oluyorlar. Uygun indekslerle aynı düzeyde, hatta daha iyi iş hacmi de mümkün olabilir. Tabii etkinlikler için akıllı bir dizin yapısı kurmadığınız sürece; bu da aslında tek boyutlu bir indeksle aynı şeydir, oysa veritabanında birden çok boyut ve boyut kombinasyonu için indeks oluşturabilirsiniz
      Sonuçta doğru; mesele uzlaşma meselesi
    • iCalendar, takvim verilerine hızlı erişim için bir depolama biçimi değil, değişim biçimi olarak tasarlandı
      Biçim yaşını belli ediyor; XML/JSON “popülerleşmeden” önce tasarlandığı anlaşılıyor
      Bkz: https://en.wikipedia.org/wiki/ICalendar
    • DBMS olmadan yapılabilir, ama verinin yine de iyi bir şemaya ihtiyacı var; bunun da iCalendar kayıtları yığını olmaması gerekir. Örneğin kararlı kullanıcı ID’leri yerine yalnızca değiştirilebilir ve tekrarlanan e-posta adresleri var
    • Böyle bir yaklaşım, yazıda bahsedilen sonsuz zaman slotu problemine de daha temiz bir çözüm sunabilir gibi

  • Uygulamalarda tekrarlayan etkinlikleri ele alan bir yazı; kişisel olarak benim gözümü açmıştı. Mutlaka okumanızı öneririm: https://github.com/bmoeskau/Extensible/blob/master/recurrenc...

    • Orijinal yazıdaki tavsiyeyle bu yazıdaki tavsiyenin birbirine zıt olması ilginç
      Orijinal yazı her tarihte her zaman saat dilimini saklayın diyor; bağlantı verilen yazı ise her şeyi UTC’ye çevirin diyor. Bu konuda orijinal yazıya katılıyorum
      Orijinal yazı her etkinlik için veritabanında bir satır oluşturun diyor; bağlantı verilen yazı ise bunu yapmayın diyor. Bu konuda bağlantı verilen yazıya katılıyorum

  • Bir mülakatta en büyük çuvallamam, basit bir rezervasyon sistemi yaparken tekrarlayan rezervasyonları da işlemem gerektiği zamandı
    Üniversitenin ilk yıllarından beri kodla bir şey başarmaya çalışırken kendimi bu kadar kaybolmuş ve kafası karışmış hissetmemiştim. Hâlâ tarih/saatle ilgili iş yapmam gerektiğinde önce korkuya kapılıyorum; neden bilmiyorum ama kafamda bir türlü yerine oturmuyor

    • “Tekrarlayan rezervasyonları da içeren bir rezervasyon sistemi tasarla” şeklindeki tasarım sorusu, “string listesini sıralayan bir fonksiyon yaz, ama rastgele UTF-8 string’leri ve tüm yerellerdeki alfabetik sıralama geleneklerine uymalı” sorusuna benziyor
      Dışarıdan basit görünür, ama gerçek dünyada genel olarak çalışacak hale getirmeye çalışınca imkânsız denecek kadar karmaşık bir probleme dönüşür
    • Kendini fazla hırpalamana gerek yok. Bir CMS’in takvimini geliştirip çok daha fazla özelliği desteklemesini sağlama işi bana verilmişti ve neredeyse beni yutuyordu. O sırada yaklaşık 8 yıllık deneyimim vardı
      Bu aldatıcı derecede zor bir problem ve çok iyi veri modelleme becerisi gerektiriyor

  • Sistemleri modelleme becerisi hafife alınıyor. Yeni bir alanda, sistemin statik yapısını, yani sınıf modelini ve dinamik davranışını, yani kullanım senaryolarını yakalayabilmek için problemin tamamının analiziyle başlamak gerekir
    Doğrudan statik veritabanı modeline atlamak, dinamik davranışın kaçırılmasına yol açabilir. Böyle basit CRUD uygulamalarında sorun olmayabilir, ama daha karmaşık sistemlerde büyük bir hata olabilir

    • Bir veri bilimci olarak, görünüşte basit “şemayı nasıl kurardınız” mülakat sorularında birkaç kez o anda epey zorlandığım oldu
      Hatırladığım son soru, kuponları olan bir ürün tablosunu nasıl tasarlayacağımdı. Başta iki tablo yeter sanmıştım; ama geçmişi de tutmak gerekmez mi? O zaman ürün ve kupon bazında tarih/saat ekleyip güncellemek gerekir. Şimdi tablo indekslerini de düşünmek gerekiyor; indirimli fiyatı almak için join yapmak iyi bir yöntem mi, onu da sorgulamaya başlıyorsunuz. Çoğu kuponu bir kişi yalnızca bir kez kullanabilir; bunu nasıl uygulayacağız?
      Muhtemelen sadece basit bir ürün + kupon tablosu istiyorlardı, ama ben kendi kendime uzun süre çılgınca derinlere daldım
    • Böyle bir analizin çıktısı nasıl görünür? Örnek bir doküman ya da bir kitap bölümü gibi referans bağlantılar varsa merak ederim

  • Modellemeyi göstermek için iyi seçilmiş bir alan ve iyi bir giriş yazısı olduğunu düşünüyorum
    “anchor” terimi biraz garip geliyor, ama açıklaması gerçek bir çapa gibi çok somut ve yere basan nitelikte olduğu için yeterince işe yarıyor gibi
    Özellikleri sorular üzerinden tanımlama fikri sağlam. Hangi sorulara yanıt vermeye çalıştığımızı tanımlamadan doğrudan asgari sütun/özellik adlarına atladığımız çok oluyor; böyle olunca müşterinin kafasındaki muğlaklığı temizleyemiyoruz. Soru temelli özellik tanımı, hızla netlik kazanmanın iyi bir yolu

    • “anchor” terimi Anchor Modeling’den (https://en.wikipedia.org/wiki/Anchor_modeling) geliyor. “Entity” yaygın kullanılıyor, ama gereksiz yük ve varsayımlar getirebildiği için kullanmak istemedim
      Ayrıca bu terim aşırı derecede çok anlam yüklü. Bilgisayar biliminde neredeyse her şey ya nesne ya da entity’dir
      Özellikleri sorularla tanımlama fikrinin sağlam bulunması, bu yaklaşımın geçerliliği açısından önemli bir doğrulama oluyor

  • Saat dilimleri, özellikle geçiş anlarının çevresinde insanın aklını karıştırır
    Saat diliminin yaz saati uygulamasında bir saat ileri atladığını, standart saate dönerken de bir saat geri gittiğini varsayalım
    Saat bir saat ileri atladığında, 1 saatlik bir etkinlik ekranda 2 saate yayılmış gibi görünebilir; o ikinci saate ise ulaşılamaz ya da o saat hiç yoktur
    Saat bir saat geri alındığında, 1 saatlik bir etkinlik 2 saat gibi de görünebilir, 0 saat gibi de görünebilir
    Saat dilimleri insan yapımı yapılardır; bu yüzden değerleri sabit kodlamamak gerekir. Bir gün değişirler

    • Hareketi de hesaba katarak zamanı izlemek daha da ilginç hale gelir. Bunu ilk kez, birkaç gün denizde kalan bir gemide zamanı izlerken yaşamıştım
      Saat dilimleri arasında iki yönde de tekrar tekrar geçiş yapabilir, tarih değiştirme çizgisini aşabilir ve yerel başlangıç tarihi/saati yerel bitiş tarihi/saatinden sonra gelebilir
    • Bu, takvimi saat dilimi olmadan tamamen UTC ile yapalım mı demek? Saat dilimlerinin bizim oluşturduğumuz şeyler olduğuna katılıyorum, ama daha iyi yerel organizasyon için oluşturuldular. Dünyanın dört bir yanındaki müşterilerle çalışıyoruz ve herkes saat dilimi kullanıyor. Kişisel olarak oldukça mantıksız bir talep gibi görünüyor
      Bunun yerine, hâlâ yaz saati uygulamasını kullanan bazı bölgelerde yaz saati uygulaması kavramını ortadan kaldırmaya odaklanmak daha iyi olur. Özellikle yaklaşan geçişten sonraki planları yaparken saat dilimleri arasındaki en fazla kafa karışıklığına bu neden oluyor

  • Etkinlikte iki tarih saklamak istemem. Etkinliğin başlangıç zamanı ve süresini saklamak daha kolay
    Böylece etkinlik güncelleme mantığı basitleşir. Bitiş zamanı, başlangıç zamanı ve süreye göre her zaman hesaplanabilir

    • Dürüst olmak gerekirse üçü de, yani başlangıç, bitiş ve süre saklanıp amaca göre gereken kullanılabilir. Alternatif gösterimleri senkronize eden tek bir giriş/güncelleme noktası olması yeterli
    • Bu yaklaşım veritabanı performansında sorun yaratabilir. Her sorguda süreyi anlık olarak hesaplamak gerekir
    • Tersi de aynı değil mi? Başlangıç ve bitiş varsa süreyi kolayca hesaplayabilirsin

  • Eskiden tekrarlayan etkinlikleri olan bir takvim uygulaması üzerinde çalışmıştım. Epey araştırmadan sonra bunu ifade etmek için RRules kullanmaya karar verdik ve bundan çok memnun kaldım. O ilk işi bir ajansta çalışırken yapmıştım
    Daha sonra o şirkete tam zamanlı katıldığımda, başka bir şirketten gelen bir yüklenicinin RRules’u kaldırıp etkinlik örneklerini anlık olarak oluşturup silen bir yaklaşıma geçtiğini görünce şaşırdım. Hata toleransı neredeyse yoktu; başka işler de yapan ve ara sıra başarısız olan bir script yeni etkinlik oluşturmayı bazen başaramıyordu. Böyle olunca aylık tekrarlayan etkinlikte eksik aylar oluşuyordu
    Üzerinde çok düşünüp araştırarak oluşturduğumuz bir şeyi birinin aynı düzeyde emek harcamadan kaldırması çok sinir bozucuydu. O şirkette birkaç hafta geçirmek bile CEO’nun mühendislik ekibinden, kimsenin kullanmadığı özellikleri kendi istediği şekilde durmadan üretmesini beklediğini anlamaya yetiyordu; işe alım piyasasındaki belirsizlik yüzünden ne yazık ki 2 yıl kaldım
    Bu arada, sonradan aradığımda Glassdoor’da CEO’nun yazdığı bariz sahte yorumların hepsinin aynı üslupla ve tek bir kötü söz olmadan yer aldığını görmek gerçekten canımı sıktı. Ben ve orada çalışmış birkaç tanıdığım ondan nefret ediyorduk; yine de o şirkette en iyi denemelerimden birkaçını yazmış olmam bir teselli. CTO da işe yaramazdı

  • Bir dönem low-code bir platform için takvim ve kaynak kontrolü backend’i geliştirmiştim
    Kontrol çok güçlü şekilde özelleştirilebiliyordu; günlük, aylık, yıllık gibi çeşitli görünümlerin yanı sıra kaynak görünümü de seçilebiliyordu. Kaynaklar özel gruplarla rezerve edilebiliyor; eklentiye göre, kaynak ID’sine göre vb. gruplanabiliyordu. Veri kaynağında “plugins” tanımlanıyor, başlangıç/bitiş sütunları, başlık sütunu ve kaynak sütunu da belirleniyordu. Kaynak, yabancı anahtardan veya 1:1 ilişkiden gelebileceği gibi, “alt” veri kaynağındaki 1:N ilişkiden ya da aynı veri kaynağı/tablodan da gelebiliyordu
    Ayrıca aylık, haftalık, belirli haftanın günleri, günlük gibi çeşitli randevu serileri uyguladık ve hangi sütun değerlerinin kopyalanacağını seçilebilir hale getirdik. Randevu çakışmalarını da ele aldık; yalnızca aynı kaynak rezerve edildiğinde çakışma sayılacak şekilde ayarlanabiliyordu. Randevuların öncesine ve sonrasına başka randevu konamayan tampon süreler de tanımlanabiliyordu
    Avrupa’daki saat dilimleri ve yaz/kış saati gibi şeyler nedeniyle zaman zaman zorlayıcıydı, ama oldukça keyifli bir işti

  • Google Calendar’da istediğim tek şey takvimin kendisine ait değişiklik günlüğü. Lütfen bunu veritabanına eklesinler