Стратегия хранения истории заказов в MySQL

[Allan Stark]

Стратегия хранения истории заказов в MySQL

Задача: обеспечить хранение последнего заказа для каждого заказчика (т.е. последнюю заявку). Необходимо для облегчения составления новой заявки (они достаточно типовые). Заявки могут быть как на десяток позиций товара, так и на пару сотен. Примерное предполагаемое количество постоянных клиентов компании - до 400 шт. Предполагаемая нагрузка - до нескольких десятков заказов (заявок) в день. Типовая заявка - простейшая, товар (ID и наименование), стоимость, кол-во. Дату последней заявки думаю хранить прямо в базе пользователей (иначе, если клиент никогда не создавал ее через интернет - попросту NULL).

Вариант решения, на котором пока остановился.
Создавать под каждого пользователя динамически типовую таблицу заявки с именем по принципу lastorder_userid. Т.е. у нас кол-во таких таблиц в отдельной базе будет примерно равно кол-ву активных (т.е. сделавших заявку через интернет) пользователей.

Хочу посоветоваться, может можно это дело реализовать как-то иначе ?
До сих пор программировал лишь временные заказы, которые после отсылки сразу уничтожались.

В перспективе хотелось бы конечно обеспечить хранение истории заявок скажем до 3-х включительно (больше не нужно).

 

[svetasmirnova]

А зачем таблицу под каждый заказ? Не проще одну таблицу и user_id?

 

[MuXa247]

Re: Стратегия хранения истории заказов в MySQL

Автор оригинала: Allan Stark Вариант решения, на котором пока остановился.
Создавать под каждого пользователя динамически типовую таблицу заявки с именем по принципу lastorder_userid. Т.е. у нас кол-во таких таблиц в отдельной базе будет примерно равно кол-ву активных (т.е. сделавших заявку через интернет) пользователей.

Никогда так не делай!
Делаешь отдельную таблицу по заказам с инфой заказа: id заказа, user_id, имя клиента, адрес и т.д.
плюс таблицу с товарами каждого заказа:
id заказа, id товара, количество, стоимость(если стоимость меняется у товаров)

Но для такого вида нельзя чтоб товары куда либо исчезали из таблицы товаров, иначе будет ошибка в данных...

 

[Allan Stark]

svetasmirnova
Это тоже рассматривал. Только так по моему немного усложняется задача - имеем ведь одну большую таблицу (примерный макс. размер 400 пользователей * 300 строк заказа = 120000 записей, причем в каждую еще стоит добавить помимо userid поле даты заказа (не в коем случае не время !), его номера и т.д.

Не знаю, мне вариант с максимумом 400 таблиц-заказов в отдельной базе как-то больше нравится. Тем более что для сервера это не нагрузка, а оперировать ими легче, чем копаться в одной большой таблице.

 

[MuXa247]

Allan Stark
Ты сильно заблуждаешься... Почитай доки по базам данных. А таблица в 120000 записей - ну совсем не большая!

Плюс вопрос почему не хранить дату со временем, а только дату?

 

[Allan Stark]

MuXa247
Возможно вы неправиьлно меня поняли. В справочнике заказчиков будут поля last_order (которое будет попросту отвечать за дату последней заявки) и last_order_num - поле порядкового номера последнего заказа. За каждым пользователем также будет закреплена таблица типа tlast_order_from_user_id-пользователя, которая будет создана когда пользователь сформирует свою первую заявку или которая просто перезапишется, когда он создаст 2-ю и последующие.
Единственное замечание - некоторые проблемы с безопасностью, ведь размещая два вышеназванных поля в базе заказчиков мы тем самым даем на нее права insert и пр. Однако решается путем создания отдельной простенькой вспомагательной таблицы.

 

[Фанат]

про безопасность мощно задвинул

 

[Allan Stark]

MuXa247
Да, конечно она небольшая. Возможно вы и правы. Так получается мы имеем таблицу формата:

1. ид-пользователя
2. ид-товара
3. стоимость товара
4. кол-во товара
5. дата заказа
6. номер заказа

Правильно ? Только вот такое кол-во присутствия "вхолостую" полей номера заказа и его даты немного неоправдано... Наверно тогда стоит создать отдельную вспомагательную таблицу и вынести эти два проблемных поля туда вкупе с ид-пользователя, а выборку делать общую.

Да, наверно это есть лучший выход...

 

[MuXa247]

для последних заказов сделай дополнительную таблицу в которой будет всего 2 поля: id пользователя , id заказа
И еще раз повторюсь: НЕ плоди кучу не нужных таблиц!

 

[Фанат]

здесь только форджест поможет.
только ему хватит терпения копаться в той помойке, которая лежит в голове у нашего друга Allan Stark, и последовательно объяснять те _многоуровневые_ залежи заблуждений, которые там лежат.

на мой же взгляд, разговор должен быть короткий.
человек спросил, как правильно - ему ответили.
не нравится - никто не заставляет. делай, как хотел.
но зачем настаивать-то?

-~{}~ 08.09.05 12:49:

Только вот такое кол-во присутствия "вхолостую" полей номера заказа и его даты немного неоправдано...

кто-нибудь мне объяснит - почему вхолостую?

 

[Allan Stark]

Фанат
Изначально доступ к базе заказчиков предоставляется по письменной заявке т.е. практически вручную а не через регистрацию на сайте.
Отож.

-~{}~ 08.09.05 12:52:

Фанат
К сожалению никто не совершенен... В особенности личности, старающиеся в силу необъяснимых причин показать свое превосходство и наводняющие технический форум множеством бесплодных комментариев вместо того чтобы хотя-бы просто промолчать...

 

[MuXa247]

Автор оригинала: Allan Stark
Фанат
Изначально доступ к базе заказчиков предоставляется по письменной заявке т.е. практически вручную а не через регистрацию на сайте.
Отож.

Круто! Сайт теперь надежно защищен...

 

[Allan Stark]

MuXa247
Спасибо. Решил делать все в одной таблице + доп. таблица.
Вы и svetasmirnova переубедили наглядно.

 

[Фанат]

Allan Stark
дело не в том, что моё превосходство.
а в том, что ты споришь с вещами уровня букваря SQL.
И если ты этого не понимаешь, то да - твой уровень ниже плинтуса.
только это не оскорбление, а факт.

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

по хорошему, с такими вопросами, тебя надо сразу и молча, без "бесплодных комментариев " отфутболить читать теорию баз данных.
ты этого хочешь? я быстро организую.

-~{}~ 08.09.05 12:57:

доп. таблица

абсолютно бессмысленная таблица.

 

[Allan Stark]

MuXa247

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

 

[alexhemp]

Allan Stark

Ты бредишь. Почитай теорию построения баз данных.
Защита данных к их структуре не имеет ни малейшего отношения.

Сперва сделай нормальную структуру БД - как тебе советуют нормальные люди, а потом уже дальше пиши в форум свои "вопросы".

Я дам тебе подсказку.

1. Заказ и товары в заказе - разные вещи. Храни их в разных таблицах, используя связь между ними.
В таблице заказа - один заказ - одна строка.
В таблице товаров заказа - ссылка на заказ и несколько строк описывающих заказанные товары, один товар - одна строка (в ней количество, цена и т.п.).

2. Последние заказы для каждого user_id вычисляются ПРОСТО. Это элементарный запрос к БД. Ничего не надо хранить, нужно ИЗВЛЕЧЬ данные. Подскажу - это группировка по User_id и MAX(Date).

Когда это будет понятно - приходи еще.

 

[MuXa247]

Автор оригинала: alexhemp
Allan Stark
2. Последние заказы для каждого user_id вычисляются ПРОСТО. Это элементарный запрос к БД. Ничего не надо хранить, нужно ИЗВЛЕЧЬ данные. Подскажу - это группировка по User_id и MAX(Date).

все еще проще:
select * from zakazi where user_id=$user_id order by zdate desc limit 1

 

[Allan Stark]

MuXa247
Да знаю я...