FilemakerTurk, AYS Bilişim ve Beyaz.net tarafından desteklenmektedir.
Filemakerturk.com a Hoş geldiniz. FilemakerTÜRK bir yardımlaşma portalidir. Sorularınızı yazarken teknik anlamda güçlük çekiyorsanız. Telefonda bize anlatın sizin yerinize siteye biz yazalım 0532 231 07 27 Mehmet KAYA.
Filemaker Lisans İhtiyacınız için FilemakerTürk Yönetimi ile iletişime geçin
 
Alakalı Siteler:

AYS Bilişim


Cabitaş



Göksel GÖKÇE


Briandunning
 

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

+4 oy
28,924 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 (31,640 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.

3 Cevaplar

+2 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 (36,800 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...
+1 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 (89,250 puan) tarafından cevaplandı
bu biraz mky modeli olmuş bune ya :) Maşallah diyelim
+1 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 (50,340 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ış.
...