FilemakerTurk, AYS Bilişim ve Beyaz Net tarafından desteklenmektedir.
Filemaker Danışmanınız
AYS Bilişim
Mehmet KAYA
 0532 231 07 27
 0216 318 55 80
 mkaya@aysbilisim.net
						

Filemaker Data Modellerinden hangisini çözümlerinizde kullanıyorsunuz?

+7 oy
71,873 kez görüntülendi

Filemaker ile yaptiginiz cozumlerde siz hangi data modeline uygun olarak calisiyorsunuz?

Ben yillardir orumcek agi seklinde calistim ve son calismalarimi Anchor Bouy modeli ile uygulamaktayim. Bu model bana gore zahmetli ama bir o kadarda sistematik bir calisma gerektirmekte. Ve diger programcilar tarafindanda rahatca anlasilabilinecek bir model. Siz hangi modeli nicin uyguluyorsunuz? Biraz anket tarzi bir soru oldu.

Anchor Bouy modeli:

Anchor Bouy modeli Filemaker dunyasinda oldukca cogunlukla tercih edilen bir iliski modeli.

Bu modelde kullanilan mantik su sekilde islemekte. Butun layout'lar ana bir tablo uzerinden kullanilmakta ve bu ana tablo ya saga dogru alt tablolar ile iliskilendirilmekte. Bu modelde daima sol tablodan sag tabloya dogru gidilmekte ve asla sagdan sola geri gidilemez, ama gerektiginde tekrardan ana tabloya atlama yapilir. (Bu atlama Layout degisimi ile gerceklesir)

Tablolari isimlendirmede sahsen benim uyguladigim method iliskilendirmenin yapildigi tabloyu herzaman buyuk harfle yaziyorum ve gelinilinen tabloyu kucuk harfle yaziyorum.

Ornek:
Anchor Bouy Modeli

Bu method ve diger methodlar hakkinda goruslerinizi bekliyorum.

9, Mart, 2015 Database kategorisinde Hamit Özsönmez (56,370 puan) tarafından soruldu
9, Mart, 2015 Hamit Özsönmez tarafından düzenlendi
karizmatikalem Soruyu sormuşsun içerisinde de cevabı vermişsin. En iyi cevap olarak senin cevabı seçecektim ama seçemedim. Bu yüzden en iyi cevabı DOCTRIN kaptı :)
En guzel yorum bencede bu sizin yorumunuz oldu :D:D:D
Saka bir yana her bir arkadasin fikri bir birinden degerli.

4 Cevaplar

+3 oy
 
En İyi Cevap
Bu yöntem güzel bence, ama burda esas önemli olan bence minimum düzeyde relation kurarak işleri çözmektir.Çünki her relation demek aynı zaman da performansdan yiyecektir.Birde mecbur olduğumuz relationları kurarken text üzerinden değilde olabildiğinde ID üzerinden kurmalıyız ve onlarda number içerikli olursa program çok daha hızlı çlışırçünki arka planda hep çalışan sonuçta  sayılar.Ve find yaptırırken kullanıcıya related alanları find modunda pek açık bırakmama gerekiyor eğer oraya bir arama kriteri yazılırsa çoğu zaman uzun sürüyor araması, kontrol altında tutmak da fayda var.
9, Mart, 2015 DOKTRIN (39,970 puan) tarafından cevaplandı
9, Mart, 2015 Mehmet KAYA tarafından seçilmiş
Benim sizin cevabınızdan anladığım;mümkün olduğu kadar filemaker'in kendi özelliklerini kullanmalıyız.Sonuçta her relation ve script birer sorgulama.

Ama Karizmatikalem kardeşim gerçekten başarılı bir ilişkisel veritabanı kullanıyor.biraz araştırdım Anchor Bouy modelini.Sırf bunun üzerine semirnerler falan verilmiş.

Diğer üstadlardan da yorum bekliyoruz modellemeler hakkında...
+2 oy

Bahsettiğim Yıldız Gemi nin yazılımı işin %20 bu kadar. Bir isim veremedim ama biraz uğraşsam Anchor Bouy modeli ne benzeyecekmiş.

filemaker relation

9, Mart, 2015 Mehmet KAYA (165,360 puan) tarafından cevaplandı
bu biraz mky modeli olmuş bune ya :) Maşallah diyelim
+2 oy
Çözümlerimde Anchor-Buoy/Squid ve Single File modelini kullanmaktayım. Data Separation'ına geçmeyi planlıyorum. Anchor-Buoy, ERD'min kolay anlaşılabilmesini sağlıyor. Diğer taraftan her bir layout için bir anchor kullanmaya dikkat edin. Diğer türlü yani buoy'lara layout atarsanız hesaplamalarda ve scriptlerde çakışma ve problemlere neden olabilir.
14, Mart, 2015 Recep Güney (69,500 puan) tarafından cevaplandı
Uygulamalarinizi bende ayni sekilde benimsiyorum. Ozellikle data modelini separation olarak kullanmak biz developerlar icin cok onemli. Birileri verileri girerken biz rahatca layoutumuzu duzenleyip ve sonra sadece layout dosyasini guncelleyerek veri kaybi veya bu konuda ozellikle yapilmasi gereken islemlere gerek kalmiyor.

Anchor-Buoy modeline bende henuz yeni gecis yaptim ve bu cok zahmetli gibi gozuksede daha sonraki degisiklikler icin veya bir baska developer icin anlasil kaliyor.

Siz her layoutunuzu farkli bir tablo ilemi basliyorsunuz? Bu konuda bazen ben kararsiz kaliyorum. Cunki ayni taployu farkli layoutlardada kullanmak mumkunken farkli tablo ile baslamis olmak icin farkli bir tablo yaratmak zorunda kaliniyormusum gibi.
Evet, aynı context içinde farklı layoutlar kullanmak doğru bir yaklaşım değil. Diğer yandan 1 layout için 1 TOG (Table Occurence Group) çok daha fazla TO kullanmanıza ve diagramınızın büyümesine neden olsa da yukardaki sebeplerden dolayı tercih etmemekteyim.
Her layout icin farkli bir tablo kullanirken, bunu siz raporlar icindemi uyguluyorsunuz? Gerci rapor yada normal form olsun fark etmemesi gerek.
Bence önemli olan root'un altında 2. bir layout bulundurmamak.

Böylece aynı TOG içinde 2 farklı layoutun birbirlerinin hesaplamaları ve scriptlerini vb... değiştirmelerinin önüne geçmek.
Evet, doğru.
Güzel paylaşım emeğinize sağlık. Çokta güzel bir ilişki örneği, olması gerektiği gibi herşeyi ID ile bağlanmış ve ilişkili tablo isimleride anlaşılır bir şekilde tasarlanmış.
+1 oy

Ben kendi okulum için bir yönetim sistemi oluşturmaya çaışıyorum, proje büyüdükçe içinde kayboldum :) sonra selector connector modeli ile veritabanını yeniden oluşturdum. Şimdi de data seperation entegre ederek layout ve datayı birbirinden ayırmakla uğraşıyorum.

Birden çok kişinin çalıştığı ya da orta ve küçük bir projede Anchor Buoy modelini tercih ederdim.

Selector connectorda genelde Magic key ile oluşturulan kayıtların benchmarkta düşük sonuçlar elde ettiğini okumuştum. Dolayısı ile selector connector modelinin anchor buoy modelinin üzerine bir performans avantajının olmadığını söyleyebilirim. Fakat kodlamada ciddi avantaj sağladığını düşünüyorum. Bu modeli 2015 de icad eden olmasa da pazarlayan Tog Geist da bu modelin kapsamlı projeleri kolaylaştırmak amacı ile uygun olduğunu belirtmiş. Örneğin öğrencileri oluştururken bir kez oluşturduğum ilişki tablosu ile daha sonra defalarca farklı layot ve scriplerde öğrenciye bağlanmak için aynı ilişki tablosunu kullanabildim. Dahası daha önceye göre veritabanı şemasına da daha az bakar oldum. Eski haline göre çok daha derli toplu bir hale geldi diyebilirim.

Bu modelde temel olarak tüm layoutlar session tablosu üzerinden çalışır. Connector tablosu sizi tüm tablolara bağlar. Selector tablosu içinde oluşturacağınız global alanlar ile istediğiniz veriye bağlanırsınız yada magic key yöntemi ile kayıt oluşturabilirsiniz. Ekran görüntüsünde gördüğünüz üzere ben selector tablosunu klonlayarak bir de Globals tablosu oluşturdum ve layout üzerinde kullandığım globalleri burada topladım yani front end de kullandığım bağlantıları mümkün olduğunca global tablosundan back end de (yani layoutta kullanmadığım) ilişkilere ise selectordan bağlanmaya çalıştım

Çoklu kullanıcı olan uygulamalarda güncelleme yapmak gerekecek ise Data seperation kullanılması gerektiğini düşünüyorum. Data seperation yaparken sistem kullanıcılarını oluştuturken ve giriş yaparken filemakerın kullancı sistemindense kendi kullanıcı sisteminizi oluşturmanız bu modelde karşılaşabileceğiniz en önemli güncelleme sorununu çözecektir.

21, Ekim, 2018 selmanguven (500 puan) tarafından cevaplandı
Güzel bir değerlendirme olmuş Selman bey. Önümüzdeki ayın son haftası Mehmet bey bir toplantı organize ediyor, vaktiniz müsaitse önerim bunu sizden yüze yüze dinleyelim.

Küçük bir yorum, FM17 ile gelen data migrator tool ile yeni sürümde data aktarımı oldukça pratik bir hal alıyor. Data seperation model olmadan da pratikçe günsel sürümü yayınlayabilirsiniz.
migrator tool'a çalıştım teşekkür ederim, önceden bilmiyordum.
Teklifiniz için teşekkür ederim, malesef katılamayacağım fakat elimdeki çalışma tamamlanınca ki bana göre bir yılı var paylaşmayı düşünüyorum
Selman bey, elinizdeki çalışmayı değil buraya yazdığınız yönetimden kısaca bahsedersiniz diye düşünmüştüm. O tarihlerde İstanbul'da iseniz dinleyici olarak da katılabilirsiniz. Amaç FileMaker kullanıcılarını bir araya getirmek.
...