Komponent stok takip sistemi için veritabanı tasarımı

[nt]

Sayfaya etkileşim eklemek için ben javascript ve ajax eklerdim.

senin vereceğin taktikler bile yeter, kod kısmı en basiti bana bilgi ve tecrübe gerek.

component ekleme ve silme işlemlerinde ajax kullanılacak sizinde dediğiniz gibi .

Django güvenlik kısmında iyi destek veriyor, zaten biliyorsun sonuçta kırılamıyacak şifre yoktur bunu ben değil can sıkıntısından nasa yı hackliyen arkadaş söylüyor "hiç bir sistem güvenli değil" diye

 

[nt]

osm için aynısını yaptım documents tablosuna primary key eklemedim o eksik bi kontrol edersen abi @taydin

 

[taydin]

Niye iki ayrı database schema var anlamadım.

 

[nt]

Niye iki ayrı database schema var anlamadım.

bu kullanıcı girişi olan ana proje diğeri senin private

 

[taydin]

bu kullanıcı girişi olan ana proje diğeri senin private

ayrı iki tane ile uğraşmaya gerek yok bence. Bir tanesine odaklanalım.

 

[nt]

ayrı iki tane ile uğraşmaya gerek yok bence. Bir tanesine odaklanalım.

bunda hata varmı abi documende key eksik sadecce onun dışında bişey yoksa buna devam edeyim

 

[taydin]

çok kullanıcılı olan ile mi devam ediyoruz?

 

[nt]

evet abi pushluyorum birazdan bir hata alıyorum düzeltemedim

 

[nt]

çok kullanıcılı olan ile mi devam ediyoruz?

private sana özel abi sen public yeremi gircen componentleri olmaz

 

[taydin]

Evet bence iyi seçim. Çok kullanıcılı sistemin kendine özgü zorlukları olacak, onlara sonra el atarız.

 

[nt]

Private olanı paylaşırız isteyen kullanır.O sorun değilde dediğim gibi zaten çinliler seviyo bizim siteyi çökmesinler sonra uygulama

 

[nt]

envo = private tek kullanıcılı istiyen yükleyecek bunu db.sqlite3 olarak bırakıyorum
(bunu kullandın diyelim lokal biilgisayarda sonra kapattın uygulamayı zaten kayıtlı veri tabanı olduğundan sorun çıkmaz)

osm = opensource bunu postgresql e çeviriyorum çok kullanıcı için

 

[nt]

abi envo ya user eklemesi yaptım tüm modellere
bu şekilde kullanıcı senin istediğin gibi; ister cam yanı, ister şöför arkası diye. Ekleme yapabilecek

 

[taydin]

Onların hepsi "document" kategorisinde. Bu datasheet olabilir, komponentin resmi olabilir, destekleyici application note olabilir. Hatta komple bir proje içeren bir zip dosyası da olabilir. "document type" da tam olarak hangi türde olduğunu belirtiyor.

 

[ozkarah]

@taydin, @nt size işleri baştan değiştirecek bir önerim var. Gerçi bu öneri dereyi geçerken at değiştirmeye benzeyecek ama işi de kolaylaştıracak gibi.
Firebase isimli bir ürün var. Google'ın. Firebase hem database hem de storage hem de authentication desteği veriyor. Bu iş için baştan firebase öğrenmek biraz zor ama destek kısmı oldukça sağlam.

Önerim ise şu:
NoSQL'e geçmek. Gerçi @ozkarah ve @Sercan gibi hayatı veri ve veritabanı içinde geçmiş üstadlar varken bana laf düşmez ama naçizane önereyim.

NoSQL ile (ben de yeni öeğrenmeye başladım) birkaç nokta çok kolaylaşacak. Örnek olarak her parçaya detay girmeyeceksiniz. Mesela 603 kılıf %1 toleranslı bir direnç için adet, hangi kutuda olduğu ve part number tutmak yeterlidir. Nerden alınmış, ne zaman alınmış önemli değil. Ama bir IGBT için işler değişebilir. Nerden, kaça, nezaman, hangi kutuda, alınan yerin linki vb bilgiler gerekebilir.
silme işlemi ise ayrı dert. Nosql ile esnek veritabanı sayesinde bu iş daha kolay çözülür gibi. Ayrıyeten web destekli olacaksa firebase depolama ve database desteği de işi kolaylaştırır.

Dediğim gibi ben de yeni öğrenmeye başladım. Çektiğim(yada belirlediğim bir fotoyu) bulut depolamaya kaydedip erişim linkini de veritabanına girmek bana büyük kolaylık sağlayacak. Veritabanı ve depolama bulutta olursa her türlü pc/telefon vb arayüzden erişime açık bir arayüz de tasarlanabilir.

Ben yoğunluğun transactional (temel veri sorgulaması değil olaylara bağlı gelişen işlemler) olan süreçlerde kullanıcı sayısı çok yüksek (10K+) NoSQL yerine geleneksel ilişkisel veritabanları kullanmak taraftarıyım.

Eticaret siteleri gibi verinin bir seferde ön yüz uygulamasına hızlı gelmesi gerekli olan ama stok, satın alma vb işlemlerin az olduğu uygulamalarda NoSQL ya da nesne tabanlı veritabanları performans ve kodlama kolaylığı açısından daha kullanışlı oluyor.

Yöntem SQL sorgusu olunca veritabanı sunucusunun hangi ürün olduğu çok önemli olmaktan çıkıyor ama PostgreSQL'i tavsiye ederim.

 

[Sercan]

@fide hali hazırda benim projede herşey tamam. Zaten karmaşık filan da değil veritabanı yönetim tarafı. Depo (çekmece) yönetimi, malzeme yönetimi ve hatta malzeme bilgilerini farklı kaynaklardan çekme işlemlerini tamamladım. Ben sadece son vuruşu yapıp, mevcut sistemi neticeye bağlayamadım.

İnşallah yakın zamanda tamamlayacağım ve davetiye usulu kullanım imkanı vereceğim. Hatta kendi içinde proje ve bileşenlerin paylaşım platformu gibi aklımda daha da genişletilmiş senaryo da var. Kendi içinde bir grup olacak.

Hatta Ziya paşadan mottosu bile hazıar: Ayinesi iştir kişinin lafa bakılmaz / Şahsın görünür rütbe-i aklı eserinde.

 

[taydin]

her ürünün adına bağlasam aynı üründen iki farklı yoktur sanırım
örnek
4K1 direnç
a firmasının farkı ?
b firmasının farklımı ?

Evet aynı direnç için farklı üreticiler girebilmeliyiz. Bu önemli bir özellik. Veya diyelim yerli bir siteden direnç aldın, üreticisi belli değil. Böyle komponentler için "Generic" diye bir şemsiye üretici tanımlayacağız. Ne idüğü belli olmayan bütün komponentlerin üreticisi bu olacak.

 

[nt]

Evet aynı direnç için farklı üreticiler girebilmeliyiz. Bu önemli bir özellik. Veya diyelim yerli bir siteden direnç aldın, üreticisi belli değil. Böyle komponentler için "Generic" diye bir şemsiye üretici tanımlayacağız. Ne idüğü belli olmayan bütün komponentlerin üreticisi bu olacak.

abi bunu kullanıcı tanımlıyor tıpkı çekmece gibi benim sorunum mesela çok malzeme olduğu için

atıyorum resim çektin document olarak yükledin. Malzemeden farklı bir firmadan aldın malzeme aynı isim, yaptığı iş aynı, özellik aynı. Fakat kırmızı değil mavi .

 

[taydin]

atıyorum resim çektin document olarak yükledin. Malzemeden farklı bir firmadan aldın malzeme aynı isim, yaptığı iş aynı, özellik aynı. Fakat kırmızı değil mavi .

Aynı doküman birden fazla ürüne atanabilir. Mesela her direnç değeri için ayrı resim çekeceğine, bir direnç resmini bütün dirençlerde kullanabiliriz. Ama bu tabi sadece örnek. Ben direnç için genel bir resmi bile kullanmam. İhtiyacım olmaz. Ama mantık bu.

Şimdi, diyelim tüm dirençler için ortak bir direnç resmi kullanacağız. Bunu nasıl yapacağız? Daha önce eklenmiş bütün dokümanları listeleyip kullanıcının oradan seçim yapmasını mı sağlayacağız? Bu çok verimli olmaz. Binlerce doküman olabilecek. Onun yerine şu çözüm daha mantıklı: Yeni resim mi eklendi? O resim için bir tane HASH saklarsın, Mesela MD5. Sonra da aynı HASH değerine sahip doküman daha önce eklenmiş ise, onu doğrudan kullanırsın, çünkü yeni eklenen de onun aynısı.

 

[nt]

@taydin abi senin dediğin gibi MD5 hash ekledim yaparken önce MD5, hash, Salt ve başka bir şifreleme sonra napıyorum diyip en basit hali ile yaptım
ileri seviye olanını diğerine saklıyorum
anasayfayı diğerinden çaldım çalışıyor ama backend bağlantıları eksik onlarıda tamamlıyorum