Добрый вечер. Проектирую БД в общем-то, в первый раз.
Хотел спросить знатоков (ибо если наломал дров - то сейчас выправить будет легче, чем потом) о паре нюансов...
В БД сайта предполагается наличие пользователей (таблица ec_user ), каждый из которых может располагать операциями пополнения счета ( ec_user_payment ) и возврата денег со своего счета ( ec_user_refund ). Каждая финансовая операция (payment_id или refund_id в соотв. таблицах на EER-схеме) сопровождается указанием валюты ( currency_id из таблицы ec_currency ) и способом перевода ( source_id from table ec_source ).

Предполагается, что каждая операция может располагать только одной валютой и только одним способом перевода.
Скриншот во вложении. Уважаемые коллеги, есть ли у вас замечания или предложения по ней? Спасибо.

P.S. таблице ec_user колонка password указана не в лучшей форме, по ней я буду позднее заниматься, когда найду готовый скрипт регистрации юзеров.

Спасибо за отзывы. Рекомендации учту и переделаю.
Забегая наперед, хотел поинтересоваться решением другого вопроса:

Клиент может располагать несколькими товарами. В "жизненном цикле" товара есть группа статусов, один из которых может быть установлен в какой-либо момент времени. Статусов около 10 - от "В корзине" до "Получено клиентом"

У каждого товара - своя история смены статусов. Хотел поинтересоваться, как ее лучше реализовать: наверное, в виде отдельной таблицы item_status_history, состоящей из

fk_item_item_id (ID товара, чья история хранится, внешний ключ из таблицы товаров item)
item_history_pid порядковый номер записи об изменении статуса (Auto increment)
item_history_date TIMESTAMP
item_history_status_id (ID статуса товара)

Годится ли такой вариант на первый взгляд?
Кстати, где находится кнопка для редактирования сообщений?

Благодарю всех отписавшихся. Свободное время последних пару дней направил на дальнейшее изучение SQL, по кусочкам то тут, то там собираю :) С течением времени картина проясняется и количество ошибок становится меньше. :)

По поводу редактирования сообщений - печально.. А если кто-то в порыве гнева напечатает непечатное слово :) Или, что может случиться с наибольшей долей вероятности, совершит опечатку при написании запроса? :) Нужно следом отправлять сообщение с пометкой о том, что ошибся? :) Изначально думал, что редактирование запрещено для новичков - чтобы не дать им возможность постить рекламу, а затем ее аккуратно затирать. Ну да ладно, прошу прощения, отвлёкся.

авторПо поводу смены статусов.
Выше было уже отмечено, что нужно делать таблицу заказов, и к ней уже добавлять ID товаров(FK).
В OLTP системах это классический подход, когда делают вторую таблицу для хранения истории. Если не ошибаюсь, то это SCD 4. В основной таблице заказов делаете ID заказа, и его же транслируете в таблицу логов, по средством FK. Т.е никаких Historical_ID вводить не нужно. Вы всегда сможете посмотреть историю, по основному ID.

Таблица логов будет выглядить примерно так
ID, Order_ID, Status_ID, Date.

Order_ID - эта ваш идентификатор заказа.
Спасибо за советы.
С какой бы стороны подойти.. Думаю изложить так: в настоящий в момент времени проектирую не интернет-магазин, а скорее решение по работе с контрактами на поставку товаров.. Заказ клиента - это контракт.. Который содержит разные товары (позиции). Позиция может быть представлена, как, напр., "Карандаш", но в количестве 1 000 единиц или же, наоборот, всего одной единицей товара - станком весом 300 кг..). Чтобы не путать себя и вас, для беседы на форуме лучше буду использовать терминологию товаров и заказов, ибо внешне процесс похож на магазин. Просто ввиду специфичности деятельности товарам и их движению уделяется особо пристальное внимание.

Мне требуется логирование всех изменений, которые являются для клиента существенными и информативными (изменения цен товаров - поставщики могут давать скидки, изменения статуса товаров - отправил продавец товар, застрял товар где-то в пути или потерялся, или же случилось с ним что по дороге и потом денежку клиенту вернули - всяко бывает :))
Последнее, конечно, не хотелось бы встречать на практике, но предусмотреть такие случаи в БД крайне важно (и не просто их наличие, а еще и историю изменений, чтобы клиент был информирован обо всех изменениях и в случае проблем чтобы можно было восстановить картину).
..
Вот.. Поэтому думаю создать отдельные таблицы по истории изменения цен, истории изменения статусов товаров и еще пары характеристик. Все эти таблицы будут связаны с таблицей товаров через внешний ключ - ID товара. Есть у товара история изменений - будет храниться, нет - так нет (может, клиент решит удалить товар из корзины еще до того, как решит оплатить заказ).

Для этого думаю установить опции ограничения внешнего ключа как ON UPDATE: CASCADE, ON DELETE: CASCADE, чтобы при удалении товара клиентом или оператором удалялись и все сопутствующие записи, НО при условии, что статус товара младше "выкуплен". Если статус будет старше - php должен будет вернуть ошибку, т.к. актуальный товар (по которому уже пошли денежные транзакции и начались записи в истории изменений) удалять из БД нельзя. Такой вот компромисс между гибкостью и целостностью БД ) Может, конечно, я где-то летаю далековато от реальности. Но пока думаю так. :)