|
|
|
Как правильно хранить данные
|
|||
|---|---|---|---|
|
#18+
Кот Матроскин, Реализовано у меня это было ещё на Access-97 (писал тут как-то), в проге для фирмы по продаже компов и железок. Работало это всё на третьем пне 800Мгц со 128мб оперативы... такой обычный офисный комп того времени. Было: 1. Полуавтомат парсинга товарной строки (сейчас с декабря, такой для mediam-а пилить начал), который: а) читал строку, разбивал по словам, разворачивал сокращения, приводил значения к каноническому виду и разыскивал к какому параметру товара оно могло бы отностися. Как результат в БД создавалась запись о товаре с до 25 параметров (то что теперь называется EAV) б) Разыскивал "похожие" по набору параметров и значений товарные позиции и сливал их в общий прайс-лист предприятия (с собственным наименованием железки). Входные товары - оставались в отдельном каталоге поставщиков (с привязкой к поставщику). Наименование новой железки давалось по первому поставщику. в) в случае коллизий (несколько похожих товаров, совсем новая строка и ряд других) - останавливался и спрашивал "Чё делать?" собственно поэтому и "полу" . Производительность: 10 поставщиков с 5-20тыс. позиций в каждом парсились за 3-4 часа. 50% времени - первый прайс. Основное время - ответ на "Что делать". Прайс (xls) в автомате на 5000 позиций парсился за 10-15 минут. Общий объем железок - в среднем около 30тыс позиций на выходе. 2. Интерфейс "продажной блондинки" - "собери себе комп", который по имеющимся параметрам железок не позволял слепить вместе мать от Olivetti с xPCI видеокартой для ISA шины (была такая). При наличии того набора параметров был прост до безобразия: каждый выбор ещё одной железки блондинкой - увеличивал набор выбранных параметров и их значений, сокращая тем самым список допустимого железа к добавлению. На экран выводился допустимый список по категориям ... блондинка только читала текст, даже не зная назначения железа: "ой, вы выбрали мать с сокетом478(подсвечен ограничивающий параметр)... к ней нет процессоров на сегодня... ближайшая поставка ... 3 дня... могу заменить (набор значений ограничивающего параметра) на сокет 960... нет? а какой параметр для Вас наиболее важен (меняем ограничивающий параметр в списке, далее по кругу)" ... результатом было выписка документов на продажу: а) счет-заказ, с-ф, ТТН и др. покупателю. Каждый документ можно было выписать только по достижению заказом соответствующего состояния (опллачен, собран, отгружен). Разрыв во времени печати - до месяца. б) заказ(ы) на поставку с автоопределением оптимальной схемы закупки (давало 5-7% к рентабельности при общей доходности в 10-15% - много) с учетом наличия, "в дороге", "транспортных" как до поставщика, так и до покупателя. Зачастую транспортная (то что собирать было не надо) возила сразу от поставщиков к покупателям (поначалу не было своего ни склада ни офиса). в) приказы для налоговой с текстом "товар, поставщика такого-то" поставить в прайс "так-то" если были переименования. 3. Интерфейс анализа продаж. Лучший поставщик, Лучший покупатель, менеджер-продаж, наиболее выгодные товары. 4. Позже были добавлены элементы СРМ для менеджеров (блокировка клиента, история клиента, задачи менеджеру, выполнение, рекламации) Писано как раз на основе предложенного решения (стал бы я предлагать то, чего сам не делал. гы). Время выписки документов - 1-3сек. Время генерации отчетов - 5-20сек. По факту подключения 11 рабочего места - MS ACCESS - лег из-за объемов которые он гоняет по сети. Точнее легла сеть. Перейти на 1С - так и не удалось... из-за невозможности работать с многомерными наименованиями товаров (вариант 1 камасутр). Направление было закрыто из-за низкой рентабельности (уже начинались продажи в сетях по ценам ниже моих входных). К слову, два из постоянных поставщиков присылали каждую неделю свежий прайс, в котором до 20% всех наименований тупо было переименовано (как объяснили после настойчивых просьб - отсройка от конкурентов). Это и была главная причина, из-за которой пришлось делать весь этот полуавтомат... задолбали со своими переименованиями. Вот чтобы нормально печатать все докуметы и была выбрана такая схема. Объем данных по факту - даже меньше чем при наличии истории. В несколько раз. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2013, 13:51 |
|
||
|
Как правильно хранить данные
|
|||
|---|---|---|---|
|
#18+
GenyСпор ни о чем. Все зависит от конкретных условий работы и требований бизнеса. PS. Хотя в этом случае я за де нормализацию, и вообще ни вижу ничего плохого в де нормализации, если это делать очень осторожно. Роль концепции денормализации велика в теории БД. 1) БД - это схема взаимосвязанных типов сущностей. 2) Результатом запроса является часть этой схемы, удовлетворяющая условиям запроса, со всей присущей БД семантикой (бесполезность "реляционных систем", в целом, и SQL, в частности, объясняется и тем, что этот фундаментальный принцип БД не поддерживается). 3) Но, не менее важно то, что результатом запроса может быть и денормализованная схема. 4) И эту денормализованную схему можно как "вычислять" каждый раз, так и поддерживать на уровне базовой схемы. 5) Простой пример (с наименованием товара) обсуждался в этой теме. Замечу, что "перетаскивание" со стороны связи 1:1 может быть сколь угодно тотальным. Например, можно разместить в записи заказа не только наименование товара, но и дату из "шапки заказа". 6) Не менее важны случаи денормализации связей. Например, для схемы A(Клиент)-->B(Накладная)-->C(Запись накладной) вы можете как в результате запроса получить схему A(Клиент)-->C(Запись накладной) так и просто поддерживать ее (то есть, поддерживать эту, формально избыточную, связь) с помощью триггеров. В случае "реляционной системы" в отношении, моделирующем C, поддерживается не только FK на отношение, моделирующее B, но и FK на отношение, моделирующее A. 7) Поскольку все это должно поддерживаться в интерактивном интерфейсе СУБД, возникает еще один фундаментальный для теории БД вопрос: а нужна ли вообще "алгебра схем"? 8) ViPRos ответил философски - она нужна для управления галактикой:) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2013, 13:57 |
|
||
|
Как правильно хранить данные
|
|||
|---|---|---|---|
|
#18+
Бредятина, В ВИПРОС такая денормализация на схемном уровне решена (вычисимая и персистентная миграция) с первого дня. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2013, 14:15 |
|
||
|
Как правильно хранить данные
|
|||
|---|---|---|---|
|
#18+
Бредятина7) Поскольку все это должно поддерживаться в интерактивном интерфейсе СУБД, возникает еще один фундаментальный для теории БД вопрос: а нужна ли вообще "алгебра схем"? 8) ViPRos ответил философски - она нужна для управления галактикой:) еще как нужна жить без обобщений - отстаться динозавром ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2013, 14:29 |
|
||
|
Как правильно хранить данные
|
|||
|---|---|---|---|
|
#18+
глобальная проблема современности - невозможность однозначной декомпозиции агрегата из разнотипных элементов что такое 4? (2+2, 1+3,...)??? агрегат не содержит в себе метода однозначной (да хоть какой иногда) декомпозиции все наши трудности связаны с этим введение алгебры схем (где схемы разного типа) помог бы решить эту проблему - агрегат бы содержал в себе граф декомпозиции но ты как диник не поцмешь этого, у тебя мир плоско-табличный (однотипный):), потому ты и в динамическую классификацию не въехал :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2013, 14:39 |
|
||
|
Как правильно хранить данные
|
|||
|---|---|---|---|
|
#18+
ViPRosеще как нужна жить без обобщений - остаться динозавром Галактика заменена некими обобщениями и динозаврами:) Для получения подсхем (в том числе, денормализованных, а это, суде по всему, и есть "обобщения") "алгебра схем" не нужна. Так что, "управление галактикой", все-таки, надежнее:) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2013, 14:43 |
|
||
|
Как правильно хранить данные
|
|||
|---|---|---|---|
|
#18+
ViPRosглобальная проблема современности - невозможность однозначной декомпозиции агрегата из разнотипных элементов что такое 4? (2+2, 1+3,...)??? агрегат не содержит в себе метода однозначной (да хоть какой иногда) декомпозиции все наши трудности связаны с этим введение алгебры схем (где схемы разного типа) помог бы решить эту проблему - агрегат бы содержал в себе граф декомпозиции но ты как диник не поцмешь этого, у тебя мир плоско-табличный (однотипный):), потому ты и в динамическую классификацию не въехал :( Еще раз - управление галактиками надежнее:) Классификаторы и Макротипы Вы обсуждать просто отказались:) Не стоит и здесь запутывать элементарные вопросы избыточной терминологией, теперь вот "динамической классификацией":) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2013, 14:59 |
|
||
|
Как правильно хранить данные
|
|||
|---|---|---|---|
|
#18+
Бредятина, ок спи дальше ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2013, 15:00 |
|
||
|
Как правильно хранить данные
|
|||
|---|---|---|---|
|
#18+
ViPRosвведение алгебры схем (где схемы разного типа) помог бы решить эту проблему - агрегат бы содержал в себе граф декомпозиции Пока, для приведенного простого примера, я вижу только предложение связи между двумя этими схемами: (A-->C) получена из (A-->B-->C)/ А зачем? Ведь A-->B-->C итак есть в БД, и ее не нужно получать "обратным вычислением":) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2013, 15:03 |
|
||
|
Как правильно хранить данные
|
|||
|---|---|---|---|
|
#18+
Arhat109, Вообще-то вопрос касался Вашей таблицы "проданные товары" и ее неоценимой помощи в построении аналитических отчетов. В приведенной стене текста описания данной таблицы не обнаружил. Ну и, извините, не могу удержаться после заявлений "это решение однозначно будет быстрее" Производительность: 10 поставщиков с 5-20тыс. позиций в каждом парсились за 3-4 часа. 50% времени - первый прайс. Основное время - ответ на "Что делать". Прайс (xls) в автомате на 5000 позиций парсился за 10-15 минут. Общий объем железок - в среднем около 30тыс позиций на выходе. У меня тоже примерно 10 поставщиков, от 3K до 100K позиций в прайсе, общий обьем на выходе - около 130k позиций. Прием одного прайса занимает пару минут (12 лет назад, когда система создавалась, и на той технике время было примерно таким же - правда, позиций в прайсах было поменьше раза в 2-3). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2013, 15:04 |
|
||
|
Как правильно хранить данные
|
|||
|---|---|---|---|
|
#18+
ViPRosБредятина, ок спи дальше "ок спи" еще менее убедительно, чем даже "динамическая классификация":) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2013, 15:05 |
|
||
|
Как правильно хранить данные
|
|||
|---|---|---|---|
|
#18+
Бредятина, сморти, возник вопрос о миграции свойств (персистентное или вычислимое) ты увидел как ВИПРОСовская миграция свойств решает эту конкретную проблему Архата :) возникнут другие вопросы и увидишь как конкретно решает их Макротип, Классификатор, Контекст, Роль контексная и т.д. бум ждать случая :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2013, 15:18 |
|
||
|
Как правильно хранить данные
|
|||
|---|---|---|---|
|
#18+
БредятинаViPRosвведение алгебры схем (где схемы разного типа) помог бы решить эту проблему - агрегат бы содержал в себе граф декомпозиции Пока, для приведенного простого примера, я вижу только предложение связи между двумя этими схемами: (A-->C) получена из (A-->B-->C)/ А зачем? Ведь A-->B-->C итак есть в БД, и ее не нужно получать "обратным вычислением":) ого, пропустл а что такое связь между схемами? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2013, 15:21 |
|
||
|
Как правильно хранить данные
|
|||
|---|---|---|---|
|
#18+
Кот Матроскин, У Вас как и ранее так и сейчас Access-97 работает, или что поумнее? :) Ваше перетаскивание также посимвольно обрабатывает КАЖДУЮ строку входного прайса, выделяя термы (слова и словосочетания), и разыскивая их в БД (EAV) с подсчетом совпавших и вычислением функции похожести - "тоже самое"? На ходу добавляя новые термы... как например решали где кончается терм в строке (вот конкретно сейчас озадачен) "альб.д/рисования.карт-обл.с/к.ГУСИ-ЛЕБЕДИ" (и ни одного пробела)? макросами Access? :) хотя ладно, тут любят сравнивать несравнимое... можем отдельно пообщаться. В том приложении, основу работы составляло три каталога товаров: "отПоставщиков" (оригинальные названия, или закупленные товары в примере - третье описание), прайс-лист (тот самый исходный каталог товаров) и "проданные товары". Первичный - от поставщиков. В него добавлялись новые товары, к нему вязались параметры товаров и много чего другого. Наименование товара - параметром не являлось и хранилось полем в самой таблице каталога (плюс ещё 5 базовых полей о товаре). В прайс переносились новые товары из каталога поставщиков или связывались дополнительной таблицей с уже имеющимся в прайсе как "синоним". То есть прайс, как такой же каталог, имел свои 6 полей о товаре (копировались) и таблицу связи с каталогом поставщиков... это разрешает переименовывать прайсовый товар "как угодно", не затрагивая наименования поставщиков... ... номер товара в прайсе - совпадает (копирование) с одним из товаров (первым) из каталога поставщиков ... "те же самые" товары поставщиков (возможно и других) попадали уже в таблицу синонимов (первый тоже), там простая связь ИдПрайса - ИдКаталогаПоставщиков... Нет товара от поставщика - в таблице связи по этому прайсу нет линков... нет данных о товаре - не продаем и не показываем. Нашли похожий - добавили линк, появились "свойства" ... всё легко добавляется, удаляется ... хранится "текущий снимок" поставщики - прайс. При создании заказа (и любого другого документа, код - один), товар из прайса (точно также) копировался в табличку тех самых проданных товаров (те же 6 полей), если его ещё не продавали ни разу , ссылка на проданный товар втыкалась в строчку заказа (что тут может быть непонятного?!?). Всё. Никакие изменения таблички проданных товаров действительно недопустимы... на то они и проданные. Конечно, к проданным товарам также поддерживалась табличка-копия проданных товаров поставщиков и линки синонимов... которые также не подлежали изменениям... ... все дальнейшие расчеты и отчетность велись по этим табличкам проданного... они архивировались каждые полгода работы, за ненадобностью тупо в бэкап. Понятно что никакой "истории" не было (нафига?). Точнее де-факто она была, просто накапливалась по мере продаж в табличках модуля продажи... ... это ваще были независимые программные модули, которые нифига друг о друге даже не догадывались... да и писались по отдельности. А теперь, ваше решение со ссылкой в строке заказа, без предварительно готовой "истории" - как будем поступать? Сильное связывание - практически всегда - недостаток. Многа буков пришлось писать и вспоминать... надеюсь теперь - понятней? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2013, 16:31 |
|
||
|
Как правильно хранить данные
|
|||
|---|---|---|---|
|
#18+
Arhat109, о пардон, про отчеты... а что в них "сложного"? Есть список строк заказов (проданных, к оплате и т.д.), есть в них же цены, скидки... есть таблички проданных товаров поставщиков со своими ценами, есть описания поставщиков, условий, описаний транспортных... тупо складываем, вычитаем, множим... что конкретно там непонятно? Да, были ситуации, когда по закрытию месяца обнаруживалось, что хитом продаж стал комп 2-х летней давности и он УЖЕ снят с производства и новых поступлений нет и не будет... так к нам в РФию одно старьё и возят... по фотикам очень хорошо помню эти "отбросы" в 0.3Мп... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2013, 16:42 |
|
||
|
Как правильно хранить данные
|
|||
|---|---|---|---|
|
#18+
Chop_модВсе очень просто: если это ошибка - она исправляется, что делать с ошибочными документами - вопрос второй. Если объект изменяет свое св-во (любое), то старое сохраняется в истории. Все старые документы останутся неизменными. Что вы ломитесь в открытую дверь, все это давным давно во всех нормальных системах сделано. А ваш подход - это 60-ые годы прошлого века. Тут даже обсуждать нечего.+1 креативщики... автоматизируют ошибки юзеров и фальсификацию учетных документов Нет. просто работают с учетными документами. Легко и ненапряжно "левой задней". А вот типовые ошибки проектировщиков - как доставляют всем тот самый гемморой, а там и до фальсификации документов недалеко (ссыль на стоны бухгалтеров - была ранее, но Вас это - устраивает как Вы уже писали) Ещё аргументы, будут? (продолжаем веселье) :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2013, 17:10 |
|
||
|
Как правильно хранить данные
|
|||
|---|---|---|---|
|
#18+
Кот Матроскин_модСм. задачку: расчитать доход от продажи товара Х (ессно независимо от его переименования) Да все аналитические отчеты накроются - зависимость обьемов продаж от времени года, от маркетинговых программ, etc. Ладно отчеты - автоматизация комплектации заказа и то начинает представлять сложности. Т.е. это решение худо-бедно работает для "полсотни позиций в каталоге и 10 единиц на складе ( в коробке из-под сникерсов), а через полгода все равно прогорим и кому нужны будут отчеты". Вот решения с пухнущей историей - могу понять как ограничивают объемы... а это?!? Сейчас у меня - более 450тыс. товарных позиций "в работе"... отдача тела страницы до 0.5сек (около 10 запросов к БД: баннеры, голосовалки, собственно товары, сопутствующие, полезные, аналитика посещений - 2.5млн. записей, и т.д.) ... как у Вас? Кто-то тут уже писал, что отчет, генерящийся минутами, а то и по часу - нормально... :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2013, 17:15 |
|
||
|
Как правильно хранить данные
|
|||
|---|---|---|---|
|
#18+
_мод, ответ - вполне достойный. Вы не один такой. Сами то там были? А то вот, один кидался терминами, да так и не смог показать - насколько сам их знает... так, допускаю надергал из журнальной статьи... :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2013, 17:17 |
|
||
|
Как правильно хранить данные
|
|||
|---|---|---|---|
|
#18+
U-gene, спор о том, что если в строках заказа стоит только ссылка на каталог товаров - это кривое проектирование и так делать не то что "не надо", а даже нельзя. ... мне тут пытаются доказать обратное, типа "история" спасает. Спасает, спасает... бюджет разработчика от разорения. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2013, 17:19 |
|
||
|
Как правильно хранить данные
|
|||
|---|---|---|---|
|
#18+
Arhat109_мод, ответ - вполне достойный. Вы не один такой. Сами то там были? А то вот, один кидался терминами, да так и не смог показать - насколько сам их знает... так, допускаю надергал из журнальной статьи... :) тебя какие термины так зацепили? скажи, объясню или дам ссылку это обычные вещи, проектировщик должен эти вещи знать много таких вещей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2013, 17:36 |
|
||
|
Как правильно хранить данные
|
|||
|---|---|---|---|
|
#18+
Arhat109... мне тут пытаются доказать обратное, типа "история" спасает. Спасает, спасает... бюджет разработчика от разорения. :) Ваши наколенные поделки стоят дороже. Не надо чужие деньги считать, вопрос чисто технический ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2013, 17:38 |
|
||
|
Как правильно хранить данные
|
|||
|---|---|---|---|
|
#18+
Arhat109, у тебя нет слабых связей (ты просто в какое то поле таблицы что то скопировал) в вот в ВИПРОС есть - вычислимое (сильная) или персистентное (слабая) и это на уровне матаданных т.е. прогеру просто галочку надо поставить ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2013, 17:42 |
|
||
|
Как правильно хранить данные
|
|||
|---|---|---|---|
|
#18+
Arhat109Chopпропущено... +1 креативщики... автоматизируют ошибки юзеров и фальсификацию учетных документов Нет. просто работают с учетными документами. Легко и ненапряжно "левой задней". А вот типовые ошибки проектировщиков - как доставляют всем тот самый гемморой, а там и до фальсификации документов недалеко (ссыль на стоны бухгалтеров - была ранее, но Вас это - устраивает как Вы уже писали )гы... левой задней работаете вы, продаете товар, которого нет на складе вы, а гемор бухам и фальсификацию доков, оказывается, делаем мы, своеобразная логика ладно это... давайте только договоримся, что больше вы не будете настолько явно приписывать мне тех слов, что я не говорил, выделенные мною слова в цитате тут уже на пробой логики свернуть не удастся - окажетесь примитивным вруном, а не толстым троллем :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2013, 17:48 |
|
||
|
Как правильно хранить данные
|
|||
|---|---|---|---|
|
#18+
хм, прочитал выборочно тему, и как то не порял. Неужели есть системы которые работают с названием товара, а не с его кодом? ИМХО все работоспособные ERP делятся на те что присваивают товару свой код (часто для старых систем) и те что берут за основу код производителя. И этот код НИКОГДА не меняется. PS есть много систем где название пишется каждый раз в таблицу заказов, и много где передается только ссылка на справочник. И у тех и у других есть положительные и отрицательные стороны. Часто в системах передающих ссылку есть в таблице заказов поля для доп. информации. Хотя чаще всего эти поля остаются пустыми. И если честно -названия товаров в работающей системе меняется ОООчень редко. Я сам 4 года работал в комманде писавшей ERP для фирм торгующих через OnlineShop, ebay + обычный магазин с кассой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2013, 18:10 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=38104961&tid=1541395]: |
0ms |
get settings: |
5ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
141ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
45ms |
get tp. blocked users: |
1ms |
| others: | 216ms |
| total: | 430ms |

| 0 / 0 |
