- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
VK приобрела 70% в структуре компании-разработчика red_mad_robot
Которая участвовала в создании RuStore
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Кто сталкивался с созданием сабжа ?
Наименований в базе около 1000. интересует как лучше составить структуру для более качественного и быстрого выхолопа.
Приходы 1 раз в неделю, в приходе обычно 10-30% количества наименований.
Нужно знать индивидуальный расход у каждого менагера суммы, даты, клиентов ну и всю возможную инфу.
Подскажите как лучше реализовать. Использоваться будет на php.
Стандартная задачка по курсу БД в любом техническом вузе.
goods {id, name, price, что еще} //Товары, возможно нужно две цены, закупочная и реализационная
managers {id, name, что еще} //манагеры
orders {id, m_id (FK->managers.id), date, type (1/0 - пришло/ушло), "вся возможная инфа"} //заказы
goods_to_orders {id, g_id (FK->goods.id), o_id (FK->orders.id), count } //товары привязанные к накладной, с учетом количества
FK если что - foreign key (внешний ключ). ID везде является PK (Primary Key)
Запросы в общем довольно просто писать. Узнать сумму товаров списанных (т.е. по отпускной накладной) каждым манагером за конкретный период например
neolord, суть понятна. Спасибо.
Меня больше беспокоят остатки. Получается для вычисления остатков получается довольно объемное вычисление. К примеру за полгода накопится около 1000 приходов, миллиона записей о продаже. Базе придется при каждом обращении все это считать ?
Или сделать дополнительную таблицу в которой складывать остатки скажем после каждого прихода ?
Остатки это типа все что приехало минус все что уехало? Можете конечно и отдельную таблицу замутить, но вообще это тоже несложно вычисляется при помощи group by - один запрос с парой подзапросов. А запросы кешируются.
Может конечно не самый оптимальный запрос, но думать особо не хотелось =)
Можно вообще обойтись без подзапросов, если в поле type хранить не 1/0 а 1/-1 и умножать это значение на count в таблице goods_to_orders при джойне =)