Javascript.RU

Создать новую тему Ответ
 
Опции темы Искать в теме
  #31 (permalink)  
Старый 24.04.2012, 16:51
х.з
Посмотреть профиль Найти все сообщения от dmitriymar
 
Регистрация: 21.11.2010
Сообщений: 4,588

Сообщение от trikadin
А почему, собственно? Ведь точности (пусть и относительной) при вычислении таких вещей удаётся добиться и в php, и в C++, и в других языках... Почему не получится в js?)
по моему, вы не то сейчас говорите
Ответить с цитированием
  #32 (permalink)  
Старый 24.04.2012, 17:57
Аватар для trikadin
Модератор
Отправить личное сообщение для trikadin Посмотреть профиль Найти все сообщения от trikadin
 
Регистрация: 27.04.2010
Сообщений: 3,417

DjDiablo, да, понял)

Сообщение от dmitriymar
по моему, вы не то сейчас говорите
Наверное, я вас не понял где-то.
__________________
Читайте:
Ты любопытный) Всё-таки, ничему в этом мире не помешает хорошая доля юмора)
Как спросить, чтобы вам ответили
Часто Задаваемые Вопросы (FAQ)
Ответить с цитированием
  #33 (permalink)  
Старый 24.04.2012, 19:43
Профессор
Отправить личное сообщение для DjDiablo Посмотреть профиль Найти все сообщения от DjDiablo
 
Регистрация: 04.02.2011
Сообщений: 1,815

Маэстро, попробую прокоментировать.

Во первых любой (кроме первых двух) подход при использовании фильтра по названию или к примеру по цене, будет бесполезен. Тут только рассчитывать.

для 4)
Если речь идёт о выборках по какому то критерию обьеденяющему множество товаров (к примеру по группе товара, или по поставщику, или складу, или ещё чему нибудь подобному), то здесь количество кэшей может быть равно количеству критериев. Но если это поиск по названию, то от кеширования толку ноль, и кешировать каждую запись конечно не нужно.
Правда мне сложно представить ситуацию при которой менеджеру вдруг понадобится сумма всех товаров в названии который есть слог "Бла" )).

Для 5)
Прежде всего работа с таблицей товаров и регистрами товаров, инкапсулируется в одну сущность, и об отдельных запросах в бд говорить уже не корректно. Прямое обращение к бд нарушит целостность базы данных.

class nomenklarura {
     function addItem($name,$price=0){
           // начало транзакции
           // запись в бд товара
           // пересчёт регистра
           // конец транзакции
     }
}

В данном случае у нас нет иного способа создать ещё один товар кроме как обратится к методу addItem класса nomenklatura. Если нужно создать 100 товаров значит нужно сто раз обратится к методу, либо передать ему массив значений и обработать его в цикле, выполнив все операции как одну транзакцию.

А вот что касается проблемы одновременного доступа, то в мускуле проблема параллелизма должна решатся на уровне транзакций ну на худой конец при помощи системной блокировки. Я пожалуй немного подумаю над этим, а потом отпишусь.

Кстатии, также было бы интересно позаимствовать механизьм счетов из 1с. Я попозже черкну как.
__________________
Лучше калымить в гандурасе чем гандурасить на колыме

Последний раз редактировалось DjDiablo, 24.04.2012 в 20:00.
Ответить с цитированием
  #34 (permalink)  
Старый 24.04.2012, 19:59
Профессор
Отправить личное сообщение для Маэстро Посмотреть профиль Найти все сообщения от Маэстро
 
Регистрация: 02.07.2010
Сообщений: 642

Сообщение от DjDiablo Посмотреть сообщение
... то здесь количество кэшей может быть равно количеству критериев.
Количество критериев может быть почти бесконечно многообразно, если в качестве критерия фильтра использовать дату/время. Например, сколько товаров (на какую сумму) поступило (или продано) с 5-го по 10-е апреля? а с 10 по 11? Также Вы говорите об ординарных фильтрах, например, выбери все товары группы "телевизоры". А как только выборка становится "мульти", так и приехали к бесконечности. Например, выбери все товары группы "телевизоры" И компании самсунг И по цене от 1000 до 2000.

Сообщение от DjDiablo Посмотреть сообщение
Правда мне сложно представить ситуацию при которой менеджеру вдруг понадобится сумма всех товаров в названии который есть слог "Бла" )).
Могу рассказать.
По морю ездят контейнера. В нумерации контейнеров жесткое правило: номер должен содержать 4 буквы, потом 7 цифр. Все морские компании (перевозчики) каким-то им неведомым способом кодируют свои контейнера, тем не менее, получается что-то типа:
MRKU3566361
MRKU3532370
MRKU1234567
...
Менеджер набирает в фильтре "MRKU"...
Ну, дальше Вы поняли
Ответить с цитированием
  #35 (permalink)  
Старый 24.04.2012, 20:33
Профессор
Отправить личное сообщение для DjDiablo Посмотреть профиль Найти все сообщения от DjDiablo
 
Регистрация: 04.02.2011
Сообщений: 1,815

Давай определимся по какому критерию определять выигрыш. Если даже в половине случае скорость запроса вместо 100мс, занимает 1мс то это уже победа. И ради тех случаев где ускоренее невозможно, не вижу сымысла отказыватся от возможности ускорить хотябы половину.

P.S. Почему морские контейнеры нельзя отправить в отдельную категорию контейнеры ?
__________________
Лучше калымить в гандурасе чем гандурасить на колыме
Ответить с цитированием
  #36 (permalink)  
Старый 25.04.2012, 18:13
Профессор
Отправить личное сообщение для Маэстро Посмотреть профиль Найти все сообщения от Маэстро
 
Регистрация: 02.07.2010
Сообщений: 642

Сообщение от DjDiablo Посмотреть сообщение
Давай определимся по какому критерию определять выигрыш. Если даже в половине случае скорость запроса вместо 100мс, занимает 1мс то это уже победа. И ради тех случаев где ускоренее невозможно, не вижу сымысла отказыватся от возможности ускорить хотябы половину.
Вообще мы как-то перескочили на другую тему. Меня не сильно беспокоит время вычисления на сервере. SQL-запрос по 10000 записям считает быстро. Речь идет о том, чтобы всё же перенести вычисления на клиента, ан не получается. При условии, что информация передается порциями, то можно формулы по строке считать на клиенте, можно на сервере прямо в SQL-запросе, а можно на сервере в PHP. Суммы по колонкам придется считать только на сервере.

Сообщение от DjDiablo Посмотреть сообщение
P.S. Почему морские контейнеры нельзя отправить в отдельную категорию контейнеры ?
Можно. И так и сделано. Вся таблица - это и есть только одни контейнеры. Но... рассказываю дальше.
Думаю что Вы знаете, что практически в каждой таблице есть такое емкое поле "Примечание". В него пишут всё. Всё, что можно и не можно.
Специфика больших корпораций заключается в том, что автоматизация бизнес-процессов постоянно опаздывает за требованиями времени. Программисты могут сделать доработку через день, через месяц, через год... а менеджеру надо "на вчера"! Менеджеры не знают языка SQL, да и к базе напрямую их не пускают. Но они - народ изобретательный, поэтому используют свой "птичий" язык. Что это значит - сейчас приведу несколько примеров по памяти.

1. Потребовалось в таблице отображать признак "Документ распечатан". Ну типа статуса такого. Пока программисты думали/делали, менеджеры договорились, что в поле примечание будут писать условный сигнал {p} (наверное от слова printed). Что происходит далее? Далее производится поиск документов по полю примечание, в котором есть "{p}"

2. Знаете, что такое колка льда? Не та что для коктейлей. Когда зимой корабль заходит в порт, то ледокол дробит перед ним лед. Это выливается в доп. затраты на перевозку грузов. Когда ввели эти затраты и их надо было учитывать менеджеры тут же начали писать в примечание {лед}. Ну а дальше поиск по "{лед}".

3. Самое внезапное - это наше законодательство. Вдруг ввели некий типа налог, который называется "пошлина евро". Что сделали менеджеры? -Правильно, в примечание пишут {evro}.

Конечно, со временем системщики анализируют все эти примечания и раскладывают по признакам, категориям в базе. Однако менеджеры продолжают пользоваться любимым птичьим языком и выборкой по ключевым словам.
Ответить с цитированием
Ответ



Опции темы Искать в теме
Искать в теме:

Расширенный поиск


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
30(1|2) редирект от сервера. Или как лучше сделать редирект при верной отсылке форма. pizzZ AJAX и COMET 2 18.02.2010 09:06