kvlknctk
MySQL kullanarak şimdiye kadar bir çok yazılım yaptım. Bu yazılımları kullanmak için yetkili olan kişileri genel olarak tablolarını ayrı tuttum. Örneğin bir CRM sisteminde Patronlar, Muhasebeciler, Pazarlamacılar diye üç kullanıcı grubum oldu. Bunların her birisini ayrı bir tablo oluşturarak konumla
MySQL kullanarak şimdiye kadar bir çok yazılım yaptım. Bu yazılımları kullanmak için yetkili olan kişileri genel olarak tablolarını ayrı tuttum. Örneğin bir CRM sisteminde Patronlar, Muhasebeciler, Pazarlamacılar diye üç kullanıcı grubum oldu. Bunların her birisini ayrı bir tablo oluşturarak konumlandırdım. Yaptığı işlemleri gerekli yere kendi IDleri ile kaydettim. Fakat burada ters giden bir şeyler doluğunu düşünüyorum. Hepsini tek bir kullanıcı tablosunda yapıp yetkilerine rollerine göre tanımlama ve yetkilendirme yapabilirim. Fakat bu an başka bir sorun olduğunu düşünüyorum. Örnek verecek olursam Pazarlamacıların araba plakasının olduğu bir kolon açmak gerekiyor. Fakat geriye kalan kullanıcı grubunda böyle bir veri olmayacağı için yine bu kullanıcıların plaka hücresi NULL kalmış olacak. Böyle gözüken bir tablo hoş karşılanmaz bence. One to One ilişkisi ile kullanıcılara bu gibi verileri tanımlamak mümkün olabilir. Fakat Kullanıcı grubu ve roller arttıkça üstüne bir de tanımlanacak değerler eklenince pivot tablolarla uğraşmak hızımı yavaşlatabiliyor.
Karışık yazılımların kullanıcı gruplandırması hakkında kabul görmüş bir standardı uygulamak istiyorum. Sizce nasıl bir yol izlemem gerekiyor?
Teşekkürler.
Karışık yazılımların kullanıcı gruplandırması hakkında kabul görmüş bir standardı uygulamak istiyorum. Sizce nasıl bir yol izlemem gerekiyor?
Teşekkürler.
0
null görünmesi aynı tabloları tekrar tekrar açmaktan daha iyidir. araba plakasını oraya direk kolon olarak açmak mantıklı mı bilemedim, ayrı bir tabloda tutabilirsin sonuçta o plaka hangi araba ?
0
genel olarak api (parse.com, jwt) sistemleri bu durumu desteklemiyor ve default olarak tek bir tabloyu hedef gösteriyorlar. işlemler bu tablo üzerinden değerlendiriliyor. Ayrı bir tablo yapsam bile bir çok iş beni bekliyor. Fakat bu önemli değil. Standartlar ne üzerine ise onu uygulamak isterim fakat nasıl aratacağım hakkında bile pek fikrim yok. Örnek veritabanlarına baktığım zaman çok çeşitli durumlar görüyorum. ayrı tutan da var. tek tabloda tutan da. hangisinin doğru olduğuna karar veremiyorum.
0
best practices user role tarzı bir şey aratabilirsin, şunu incele bi en.wikipedia.org
stackoverflow.com
stackoverflow.com
0
eğer veri tipleri birbiriyle hiç alakalı olmayan şeyler değilse hepsine ayrı tablo açmana gerek yok. hepsi insan bunların, aynı tabloda olabilirler.
users
id
name
role_id
type_id
roles
id
name (admin, demo kullanıcı, premium, vb)
types
id
name (avukat, muhasebeci, doktor)
bir kişi eğer birden fazla rol alabiliyorsa o zaman mecbur ortak tablo (roles_users veya role_user adında, hangi isimlendirmeyi seçeceğin sana ve hangi ORM'i kullandığına bağlı) açmak gerekecek. bunu yapmak zorunda kalsan bile eğer kullanıcıları users tablosunda tutuyorsan toplam 3 tablon olacak. diğer türlü yapsaydın her kullanıcı tipi için yeni bir ortak tablo açmak zorunda kalacağın için çok fazla tablon olacaktı.
isimlendirmeyi düzgün yaptığın sürece üstteki sistem güzel çalışıyor.
tabloların ID'leri için sadece id koyuyorum, başka tabloya foreign key olarak eklerken başına tablo adının tekil halini ekliyorum, user_id gibi.
ortak tablo içinse alfabetik ve çoğul gidiyorum, books_users gibi.
sütun adlarını da sade tutuyorum. user_name / user_email yerine name, email gibi.
Bir ORM bul, onun standardını kullan derim.
users
id
name
role_id
type_id
roles
id
name (admin, demo kullanıcı, premium, vb)
types
id
name (avukat, muhasebeci, doktor)
bir kişi eğer birden fazla rol alabiliyorsa o zaman mecbur ortak tablo (roles_users veya role_user adında, hangi isimlendirmeyi seçeceğin sana ve hangi ORM'i kullandığına bağlı) açmak gerekecek. bunu yapmak zorunda kalsan bile eğer kullanıcıları users tablosunda tutuyorsan toplam 3 tablon olacak. diğer türlü yapsaydın her kullanıcı tipi için yeni bir ortak tablo açmak zorunda kalacağın için çok fazla tablon olacaktı.
isimlendirmeyi düzgün yaptığın sürece üstteki sistem güzel çalışıyor.
tabloların ID'leri için sadece id koyuyorum, başka tabloya foreign key olarak eklerken başına tablo adının tekil halini ekliyorum, user_id gibi.
ortak tablo içinse alfabetik ve çoğul gidiyorum, books_users gibi.
sütun adlarını da sade tutuyorum. user_name / user_email yerine name, email gibi.
Bir ORM bul, onun standardını kullan derim.
0
Normalizasyon ve Denormalizasyon SQL konusunda en önemli soru isaretidir. Senin durumun da buna isaret ediyor. Cünkü bu konuda tek bir dogru yoktur, duruma sarta göre dogru degisir. Bircok alt tabloya bölersen (Normalizasyon) tekrarlar azalir, daha az yer kaplar ama performans olarak kayip yasarsin cünkü tablolardaki datayi birlestirirken birkac tabloyu join yapman gerekir. Parcalamaz bütün turarsan (denormalizasyon) cok tekrar olur, bazi alanlar bos olur, yer kaplar ama avantaj olarak da bazi durumlarda karmasa düser performans artar. neyin ne kadar olacagi duruma göre degisir
0
plaka gibi görece daha önemsiz ve üzerinden aggregated-report üretilmeyen alanları bir meta tablosunda key-value şeklinde tutabilirsin.
wordpress'in meta bilgileri sakladığı şekilde.
wordpress'in meta bilgileri sakladığı şekilde.
0
@fever wp bilmiyorum ama bu dediğin php serialize, unserialize konusu mu? php.net
0
