Veritabanı şema tasarım: onaylanmamış davetleri hakkında ne yapmalı?

5 Cevap php

Ben bu sorunu nasıl yaklaşım oldukça emin değilim:

Ben bir davet sadece kayıt sistemine sahip bir web uygulaması oluşturma. Bir yönetici kullanıcı, bir kullanıcı bir e-posta daveti gönderen kullanıcı bağlantıya tıklar ve onların e-posta adresi ile bağlantılı olan bir hesap oluşturabilirsiniz bir sayfaya götürüyor.

Benim ilk fikir işaretli verified kolonu false ile benim users tabloya bir satır eklemek oldu. Sorun bir kullanıcı adı ve gerekli alanları ve kullanıcı adı şifre gibi benzersiz olması gerekir. Ben sadece sonradan doldurulması gereken boş bir satır eklemek olamaz.

Ben davetler için ayrı bir tablo oluşturmak gerekir? Ne senaryo bu tür yaklaşım en iyi yolu olurdu?

Update: yönetici ad, soyadı, e-posta adresi ve kullanıcı rolü (izinleri) girecektir. Yani davetiye tablodaki tüm bu şeyleri saklamak gerekir. Ben de mağaza tarih gönderilir ve e-posta Hiç yeniden gönderilmesi gerekirse bu değeri güncelleme olabilir.

5 Cevap

Evet, davetler yönetmek için ayrı bir tablo yapmak istiyorum.

Bir davet kabul edildiğinde, sonra bir kaç seçenek var. Öncelikle size ya izleme ya da "aile ağacı" ya da diğer bazı tarihsel amaçlar için orijinal davete bir ilişkiyi sürdürmek için gerekiyorsa karar isteyeceksiniz.

Eğer öyleyse Sonra, size yapacağım nasıl karar vermeniz gerekir. Daveti silin ve kullanıcı kaydı w / ilgili herhangi bir bilgi depolamak? Davet kaydını tutmak ve bir yabancı anahtar ayarlamak?

Ben oluşturmak niyetinde sistemi hakkında daha fazla bilgi varsa biraz daha ince ayar tavsiye vermek mümkün olabilir.

Sen davetiye almak kayıp senaryoları, kaza ile silinmiş olsun, ya da diğer nedenlerle bir dizi için göz önünde bulundurmanız gerekir, kullanışlı değildir ve yeniden gönderilmesi gerekir.

Ayrıca, bir davet, bir kaydından ayrı bir varlıktır. Seni davet izlemek için vs (davet edildiği) kayıtlı kim olduğunu görmek için ayrı bir tablo oluşturmak gerektiğini düşünüyorum

Ben davetler için ayrı bir tablo öneriyoruz. Bu davet temelde birisi kayıt sağlayan bir belirteç olduğunu bana çok açık görünüyor.

Ayrı bir tablo benim için en mantıklı. Yani kullanıcıların tablodaki veri bütünlüğünü korumak için izin verecek, ve daha okunabilir bir veri modeli sağlayacaktır. Bu "doğrulanmış sütun ayarlamak false ile davetiye Kullanıcılar tablosunun gitmek ama" daha "davetiyeler davetiyeler tabloda gitmek" demek kolaydır.

Bu bakmak için yollar çift. Eğer değerlendirme aşaması bittiğinde ne olur başka bir tablo oluşturmak ayrı rota giderseniz, size gerçek kullanıcı masaya bu değerlendirme kullanıcıları kopyalamak zorunda mı? Kullanıcı adları kullanıcıların tabloya giriş işlemek için programlanmış ettik özel hazırlanmış bir GUID öndeğer olabilir.