• 06-03-2013, 23:12:41
    #1
    Merhaba arkadaşlar,

    Ciddi bir projede log tutmak için (Kayıt ekleme, düzenleme, silme, üye login ve bunun gibi işlemlerde) nesne tasarlamaktayım. Proje PHP+MySQL ama konu veri üzerine olduğu için bu kategori altına açmayı uygun buldum.

    Web tabanlı projelerde log genellikle aynı veritabanında ayrı bir yada daha fazla tabloda tutuluyor. Bu zamana kadar bu yöntemi ara sıra kullansamda pek içime sinen bir yöntem değildir. Art niyetli biri bir şekilde injection yada benzeri bir olayla veritabanına sorgu yollamaya başladığında logların akıbetide diğer kayıtlar gibi olacaktır. Bir nevi aynı veritabanında tutma işi çokda mantıklı değil.

    Alternatif olarak dosya sistemi üzerinde xml yada json da bu logları tutmak istesem, online kişi sayısı çok olduğunda sıkıntı yaşarmıyım. Yada dosya boyutu büyüdükce ram dolması, kayıt işlemleriden logu yazmak için beklemeler vs vs yaşarmıyım? bu dediğimi tecrübe eden oldumu hiç?

    arkadaşlar görüşlerinizi ve önerilerinizi beklemekteyim.

    Cümleten iyi çalışmalar.
  • 06-03-2013, 23:16:28
    #2
    SQL injection niye olsun ki girişleri filtrelerseniz ? Tek tabloda tutabilirsiniz
  • 06-03-2013, 23:54:20
    #3
    Girişleri şifrelemekten kastınız tam olarak nedir acaba? Şu yazım şeklimi :

    $sql=sprintf("INSERT INTO tablo (alan1, alan2, alan3) VALUES ('%s','%s',%s)",
    mysql_real_escape_string($_POST["a1"]),
    mysql_real_escape_string($_POST["a2"]),
    mysql_real_escape_string($_POST["a3"])
    );
  • 07-03-2013, 01:49:37
    #4
    oscoder adlı üyeden alıntı: mesajı görüntüle
    Girişleri şifrelemekten kastınız tam olarak nedir acaba? Şu yazım şeklimi :

    $sql=sprintf("INSERT INTO tablo (alan1, alan2, alan3) VALUES ('%s','%s',%s)",
    mysql_real_escape_string($_POST["a1"]),
    mysql_real_escape_string($_POST["a2"]),
    mysql_real_escape_string($_POST["a3"])
    );
    evet, tam olarak bu.
  • 07-03-2013, 02:48:00
    #5
    Log verilerini veritabanında diğer verilerle birlikte tutacaksanız log tutmayın daha iyi derim.
    İnjection olmasa bile veritabanına erişilme ihtimali her zaman vardır.
    En sağlıklı ve sistemi yormayacak yöntem ise;
    Logları bir txt'e kaydedip yada özel uzantılı bir text dosyasına,Cron job oluşturup belirli aralıklarla (örn. 1,5 saatte bir) bu dosyadaki verileri yöneticinin mail adresine gönderip, dosyadaki verileri sildirirsiniz.

    Böylece 1,5 saatte bir mailinize raporlar sağlıklı olarak ulaşır, belirli aralıklarla mail atılıp silindiği için yer kaplamaz ve yine aynı sebepten ötürü dosya boyutu büyüdüğünde yazma ve okuma işlemlerinde sıkıntı gibi bir durum olmaz.

    Bu illa maile gidecek diye bir kaide yok, bir curl isteğiyle başka bir sunucuya kaydı yapılabilir yada log dosyaları FTP üzerinden yine başka bir sunucuya aktarılabilir...
  • 07-03-2013, 04:57:06
    #6
    Kimlik doğrulama veya yönetimden onay bekliyor.
    Verileri dosyada tutmak çok mantıklı değil. Olmaz ya, olduğunu farzedin. Aynı anda dosyaya erişim olduğu zaman sıkıntı olur. Bildiğiniz gibi dosyalar açıkken veya kullanılıyorken silinemez. Mesela benim işlemimden dolayı log tutulmak için dosya açıldığında siz o dosyayı silmeye çalışırsanız sıkıntı doğar. Diğer taraftan aynı anda 2 kişi dosyayı açtıysa;

    Dosyada önceki veriler AAAAAA olsun.

    Ben bağlandım buna. Veriler AAAAAABB oldu.

    Başkası da aynı anda bağlanınca AAAAAACC oldu. Önce hangimiz kaydedersek onun verileri silinecek, sonra kaydedenin verileri tutulacaktır. Yani kaydetmekten kastım log tutulması.

    Dosyada tutulmasını çok önermiyorum.
  • 07-03-2013, 09:05:55
    #7
    wdr.leo adlı üyeden alıntı: mesajı görüntüle
    Log verilerini veritabanında diğer verilerle birlikte tutacaksanız log tutmayın daha iyi derim.
    İnjection olmasa bile veritabanına erişilme ihtimali her zaman vardır.
    En sağlıklı ve sistemi yormayacak yöntem ise;
    Logları bir txt'e kaydedip yada özel uzantılı bir text dosyasına,Cron job oluşturup belirli aralıklarla (örn. 1,5 saatte bir) bu dosyadaki verileri yöneticinin mail adresine gönderip, dosyadaki verileri sildirirsiniz.

    Böylece 1,5 saatte bir mailinize raporlar sağlıklı olarak ulaşır, belirli aralıklarla mail atılıp silindiği için yer kaplamaz ve yine aynı sebepten ötürü dosya boyutu büyüdüğünde yazma ve okuma işlemlerinde sıkıntı gibi bir durum olmaz.

    Bu illa maile gidecek diye bir kaide yok, bir curl isteğiyle başka bir sunucuya kaydı yapılabilir yada log dosyaları FTP üzerinden yine başka bir sunucuya aktarılabilir...
    Aynı veritabanında tutulma konusunda ki yorumunuza kesinlikle katılıyorum. Veri tabanında sadece şunu tutacağım : Her satıra recdate, reciip, updatedate, updateip gibi alanlar ekleyip ilk kaydedenin bilgileri ile son güncelleme yapanın bilgilerini tutacağım, hani yönetim kısmında hızlı bir şekilde bir veri görünsün diye.

    Ama gelgelelim detaylı bir şekilde tutacağım kısımda dosya mevzusunu çok fazla tecrübe etmediğim için çekiniyorum. erginkeles' in de dediği gibi problemlerin olma ihtimali yüksek. Örneğin Dosya boyutu 20 MB oldu, bu dosya her açıldığında ram' den 20 mb yiyecek, hadi ram' e razı geldik, aynı anda iki kişi kayıt eklemek isterse dosya açıksa açamayacak, hadi açtı kesin kayıt kaybolacak gibi bir hissiyat var bende .

    İlginize teşekkür ediyorum arkadaşlar. Öneri ve fikirlerinizi bekliyorum...
  • 07-03-2013, 10:00:07
    #8
    sql triger ile database üzerinde log tutmanız daha iyi değil mi?
  • 07-03-2013, 16:21:28
    #9
    aydns7 adlı üyeden alıntı: mesajı görüntüle
    sql triger ile database üzerinde log tutmanız daha iyi değil mi?
    Loglar datalarla aynı veritabanında olduktan sonra işlemi triger, procedure yada programlama dili ile yapmanın hiç bir önemi yok. Konu daha çok verileri tutmanın yöntemi değilde, verilerin tutulacağı yer problemini çözmek üzerine. Bu şekilde düşünebilirsiniz.