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

[taydin]

Bir de şunu belirteyim. Silme sonucunda birçok komponentin güncellenmesi gerekiyor ya, bunu yaparken ayrı ayrı sorgular şeklinde değil de, "transaction" şeklinde yapmamız lazım. Böylece ya BÜTÜN işlemler yapılmış olacak, yada HİÇBİRİSİ yapılmamış olacak. Bu tek kullanıcı için çok önemli değil, ancak bir bug neticesinde işlemler yarıda kalırsa sorun çıkar. Ama çok kullanıcı için kritik derecede önemli. Birden fazla kişi aynı anda işlem yaparsa database tamamen bozulabilir.

 

[nt]

Bir de şunu belirteyim. Silme sonucunda birçok komponentin güncellenmesi gerekiyor ya, bunu yaparken ayrı ayrı sorgular şeklinde değil de, "transaction" şeklinde yapmamız lazım. Böylece ya BÜTÜN işlemler yapılmış olacak, yada HİÇBİRİSİ yapılmamış olacak. Bu tek kullanıcı için çok önemli değil, ancak bir bug neticesinde işlemler yarıda kalırsa sorun çıkar. Ama çok kullanıcı için kritik derecede önemli. Birden fazla kişi aynı anda işlem yaparsa database tamamen bozulabilir.

slug yaptım abi yani her kullanıcı kendi component benzersiz bir .org/stock_page/stm64 bir uzantısı olucak artık o ne olucaksa

istersen bunu çeşitlendirebilirim tarih yada kullanıcı adı ile yada üreticisi falan gibi bu şekilde bir çakışma olmaz sanıyorum

 

[nt]

ayrıca testlerde yazdım tüm işlemler için bunları debug sırasında bakıcam şanş dileyin başlıyorum

 

[nt]

Bir de şunu belirteyim. Silme sonucunda birçok komponentin güncellenmesi gerekiyor ya, bunu yaparken ayrı ayrı sorgular şeklinde değil de, "transaction" şeklinde yapmamız lazım. Böylece ya BÜTÜN işlemler yapılmış olacak, yada HİÇBİRİSİ yapılmamış olacak. Bu tek kullanıcı için çok önemli değil, ancak bir bug neticesinde işlemler yarıda kalırsa sorun çıkar. Ama çok kullanıcı için kritik derecede önemli. Birden fazla kişi aynı anda işlem yaparsa database tamamen bozulabilir.

https://docs.djangoproject.com/en/4.2/topics/db/transactions/ yazmışlar tüm detayları dönüp okurum bunu

 

[nt]

abi add var delete eklemedim ama yaparken söz transaction yapıcam

 

[Ahmet]

abi add var delete eklemedim ama yaparken söz transaction yapıcam

bunu foruma entegre edecek miyiz?
yoksa local'demi çalıştıracağız.

 

[nt]

senden korkulur abi ilk hatam

parent_id = models.ForeignKey(blank=True, null=True)
TypeError: ForeignKey.__init__() missing 2 required positional arguments: 'to' and 'on_delete'

 

[nt]

bunu foruma entegre edecek miyiz?
yoksa local'demi çalıştıracağız.

ayrı bir sunucuda çalışacak

 

[taydin]

Çok kullanıcılı sistem işi baya karıştırıyor olacak. Herkesin kendi database'i olsa mesele yok da, herşey tek bir database'de olursa bizim mevcut şema yetersiz kalıyor.

 

[Ahmet]

Çok kullanıcılı sistem işi baya karıştırıyor olacak. Herkesin kendi database'i olsa mesele yok da, herşey tek bir database'de olursa bizim mevcut şema yetersiz kalıyor.

benim 2 tane rpi2 bu işe sunucu olamaz mı

 

[nt]

transaction tamamen başka bir sayfada yapıcam abi services.py diye bir sayfa açıp orda kullanıcam models dosyası bu şekilde kalsın karışmaz hem

 

[taydin]

transaction tamamen başka bir sayfada yapıcam abi services.py diye bir sayfa açıp orda kullanıcam models dosyası bu şekilde kalsın karışmaz hem

Tranaction görsel birşey değil. Programın içindeki bir detay. Mesela bir komponenti siliyoruz.

Transaction olmadan:

1) Datasheet dokümanını sil
2) Datasheet ile komponent ilişkisini kuran component_document_links sil.
3) Komponenti sil.

Transaction ile:

1) Transaction başlat (init transaction)
2) "Datasheet dokümanını sil" listeye ekle
3) "Datasheet ile komponent ilişkisini kuran component_document_links sil" listeye ekle
4) "Komponenti sil" listeye ekle
5) Listeye eklenmiş işlemleri tek hamlede yap (commit transaction)

 

[nt]

Hoşgeldiniz mailide güzel olur bunuda ekliyelim abi

 

[taydin]

Ohoo, sen onu da ekleyeyim bunu da ekleyeyim diye gidersen bu proje bitmez

Böyle şeylerde aslında ilk başta kullanım senaryoları çalışılması lazım. Sonra da ana kodun bu senaryoları SQL seviyesinde halledebilmesini sağlamak lazım. Mesela o konu üzerinde kafa yorunca bir sürü ayrıntı çıkıyor karşına.

* Komponent silinince datasheet'i de silinmeli mi? Belki de silmemek lazım, ileride aynı komponent eklenince lokalde saklı olan datasheet'i ekleme seçeneği sunulmalı.

* Komponent silinince alış veriş listeleri de geçersiz hale geliyor. Belki de komponent fiziksel olarak silineceğine "silindi" işaretlenmeli.

Bu tip detaylar belirleyecek yazılımın başarılı olup olmayacağını, yoksa görsel presentasyonun ne kadar iyi olduğu değil.

 

[nt]

Tranaction görsel birşey değil. Programın içindeki bir detay. Mesela bir komponenti siliyoruz.

Transaction olmadan:

1) Datasheet dokümanını sil
2) Datasheet ile komponent ilişkisini kuran component_document_links sil.
3) Komponenti sil.

Transaction ile:

1) Transaction başlat (init transaction)
2) "Datasheet dokümanını sil" listeye ekle
3) "Datasheet ile komponent ilişkisini kuran component_document_links sil" listeye ekle
4) "Komponenti sil" listeye ekle
5) Listeye eklenmiş işlemleri tek hamlede yap (commit transaction)

bu çok güzel bir gelişme oldu beni zorluyor ama olsun zoru severim şimdilik gelişme bu services.py dosyamı yazdım
ama bu transactonun da kendi içiinde bir hiyerarşisi olması gerekli sanırım

from django.db import transaction
from .models import Component, ComponentDocument, ComponentDocumentLink, StockAlert, Log

@transaction.atomic
def create_component(data):
    return Component.objects.create(**data)

def get_all_components():
    return Component.objects.all()

def get_component_by_id(component_id):
    return Component.objects.get(pk=component_id)

@transaction.atomic
def update_component(component, data):
    for key, value in data.items():
        setattr(component, key, value)
    component.save()

@transaction.atomic
def delete_component(component):
    component.delete()

def log_to_database(message):
    Log.objects.create(message=message)

doğru yoldamıyım ?

Teşekkürler

 

[taydin]

Veritabanı ile ilgili sadece konseptleri biliyorum @nt. Bunların da neredeyse tamamını DbSchema ile bu veritabanı yapısını oluştururken öğrendim. Bu konseptlerin uygulaması ile şimdiye kadar hiç uğraşmadım. Önemli olan senin işin mantığını anlaman. Anladıktan sonra bunları python'da gözü kapalı uygularsın zaten

 

[taydin]

sorum şu transaction her model için önce kendi içinde ayrı ayrı yapıp sonrada hiyerarşik şekilde birleştirmelimiyim örnek :
Category için önce kendi içinde bir transaction yazıcağım name, description, parent_id olarak sonrada genelde bunu işleyeceğim doğrumu abi

Transaction, veritabanı modelinin bir parçası değil, yapısal bir özellik de değil. Transaction, veritabanını değiştirirken alınan bir tedbir sadece. Ayrıntılara çok hakim değilim ama şu anki düşünce mantığım ile bütün database işlemlerinin transaction olarak yapılması uygun geliyor. Yoksa "bunda gerek var mı yok mu" diye kafa yormak gereksiz. En kötü ihtimalde transaction biraz gecikme yaratır ki bu gecikme de farkedilir bir gecikme olmaz.

 

[nt]

abi buna aslında çokda gerek yok ama biz örnek olarak binamıza ek yangın merdiveni yapıyoruz ben önce hepsi için sonrada genel hiyerarşik yapıda yapıcagım yapının şeması konualtında var zaten zorlanmam çok

 

[Furkan KELEŞOĞLU]

Projeyi keşke front-end ve back-end olarak ikiye bölseydiniz. Böyle bir uygulamada front-end tarafında Next.js veya devextreme react (non-commercial) kullanılabilirdi. Backend tarafında ise auth,rest ve veritabanı işlemleri olurdu. Backend için golang ve üzerinde ise fiber kullanılsa sistem jet gibi hızlı olurdu. Sqlite bu tarz proje için bana kalırsa çok düşük kalır. Postgresql kullanılması daha iyi olurdu. Ayrıca böyle bir proje için github da bir organizasyon açarsanız ve projeyi orada paylaşırsanız ilerleyen süreçlerde bu tarz bir programa ihtiyacı olan birisi oradan temin edebilir. Ayrıca tüm dünyaya geliştirmeye açmış olurdunuz.

Foruma hoşgeldin kardeşim seni buralarda görmek güzel...

 

[nt]

abi çalışıyor yine frontend tarafına geldim kaldım

https://github.com/ixnur/envo

kuru takipdeyim. şuanda çalışıyo bugsız