tabela zamowienia

Witam,

Mam sklep online z książkami. W systemie znajduje się tabela zamówienia. System zapisuje mi zamówienia, które zostały złożone, ale nie zrealizowane (klient zrezygnował i nie zapłacił za towar). Do takich użytkowników chcę wysyłać emaile. 24h i 4 dni po zapisaniu zamówienia w bazie danych. Email, będzie zawierał informacje o niezrealizowanym zamówieniu oraz ew opcji pomocy przy wyborze towaru. Jak mogę pobrać z tabeli zamówienia, które zostały odrzucone/niezrealizowane 1 i 4 dni wcześniej?

A masz w tabeli informacje z datą kiedy zostało złożone zamówienie?

Tak, mam kolumnę z datą zamówienia 'YYYY-MM-DD HH:MM:SS'.

A masz w tej tabeli kolumne, czy i kiedy zostal wyslany email powiadamiajacy?
Reszta prosta. Albo odejmujesz dwie daty od siebie (biezaca, czyli uruchomienia skryptu, lub jakakolwiek inna wybrana) i sprawdzasz ile jest dni w wyniku, albo do da ty zamowienia dodajesz x dni i sprawdzasz, czy jest mniejsze od wybranej przez ciebie daty.

Ja to tak rozumiem, jakbyś chcial zrobić coś niemożliwego:

poniatowski napisał(a):

System zapisuje mi zamówienia, które zostały złożone, ale nie zrealizowane
A tu:

poniatowski napisał(a):

które zostały zrealizowane 1 i 4 dni wczesniej
. Masz zamówienia, które nie zostały zrealizowane, a chcesz te, które zostały zrealizowane. Byś musiał założyć/odszukać tabelę w której przechowujesz zamówienia zrealizowane, albo coś doprecyzować.

Skrypt będzie uruchamiany raz dziennie o 3 w nocy przez crona. Wolałbym uniknąć zapisywania dodatkowych informacji w bazie danych. Jak z czasem napuchnie mi baza danych to będzie problem. Niby to tylko jedna kolumna, która będzie przechowywać np wartość enum(24, 96) godzin. Czy nawet tylko enum(1, 4) dni, no ale jednak to już dodatkowa kolumna, która mi nawet nie pasuję w tabeli zamówienia.

No to bierzesz WHERE CURRENT_DATE()-Date(data_zamowienia)=4

poniatowski napisał(a):

Skrypt będzie uruchamiany raz dziennie o 3 w nocy przez crona. Wolałbym uniknąć zapisywania dodatkowych informacji w bazie danych. Jak z czasem napuchnie mi baza danych to będzie problem. Niby to tylko jedna kolumna, która będzie przechowywać np wartość enum(24, 96) godzin. Czy nawet tylko enum(1, 4) dni, no ale jednak to już dodatkowa kolumna, która mi nawet nie pasuję w tabeli zamówienia.

Im więcej w bazie zapiszesz informacji, tym dokładniej to zadanie można zrealizować. Jeśli już masz problemy wydajnościowe z bazą, to zapisz chociaż sobie 'datę bazową' ostatniego poprawnego rozesłania e-maili. Zajmie to jedno pole w skali całej bazy, bo co zrobisz, gdy skrypt się
uruchomi się 5 minut później lub wcześniej? A tak na podstawie daty bazowej ustalisz, które maile zostały wysłane poprzednim razem.

@artur_bredzki z tym się też zgodzę. Takie informacje będą działały jak logi w systemie. Mówisz lepiej dać dwie kolumny w tabeli zamówienia: email_po_24h i email_po_4dniach. Dzięki temu wiemy jaki email i czy w dobrym czasie był wysłany. Noo tyle, że to dodatkowe dwie kolumny. Chyba, ze wepchać do zewnętrznej tabeli.

edit
Wepcham to do zewnętrznej tabeli. Tego złączenia i tak nie będę robił nigdzie w systemie, a tabela będzie działać jak logi.

Ile przewidujesz rekordow w tej tabelce z logami?

id, zamowienie_id, email_id, data ew. status.

poniatowski napisał(a):

id, zamowienie_id, email_id, data ew. status.

To są kolumny, ja pytałem o ilość rekordów, ale w sumie to nie jest aż takie ważne. :)

na początek około 50-200 dziennie. No, 200 to bardzo optymistycznie, powiedzmy 100 dziennie, albo i mniej.

To nie rozumiem dlaczego nie zrobisz tego @poniatowski po ludzku. Czyli Nie dodasz dwóch kolumn do tabeli zamówień:

• data_zamowienia
• data_realizacji

Przy takiej ilości danych (100*365 dni = 36,5 k rekordów rocznie) jeśli nie masz kompletnie popsutej struktury danych, to powinno działać szybko. Chyba, że będziesz uruchamiać to na kalkulatorze. Pamiętaj, że:

Premature optimization is the root of all evil.

Moim zdaniem powinieneś zmienić strukturę dopiero jeśli zacznie Ci mulić konkretnie. Bo na razie to są tylko zbędne dywagacje których nikt nie sprawdzi bez danych.