Что-то у Вас слишком сложно получается. Я менял коды неделю назад. Да ходить к гос. регистратору пришлось дважды: 1-й раз у них отключили электричество, но меня записали в очередь и сказали когда прийти; во 2-й раз (в день на который меня записали) пришлось дважды отстоять в очереди (небольшой, т.к. все были по записи) т.к. я не знал, то нужно купить и заполнить специальную форму. Но после ее заполнения, инспектор при мне все зарегистрировала и сказала, что через несколько дней я могу идти в налоговую для продления единого налога. Все это бесплатно, если не считать стоимости бланка (цену точно не помню, купил 2, примерно $1). Я оформлен как СПД (ФОП) на едином налоге, но, насколько я знаю, большинство ИТ-шников работает именно по такой схеме. В налоговую еще не ходил, поэтому возможны какие-то «недоработки», но смена КВЭДов, в целом, прошла относительно легко.
Кстати, начиная со следующего года продлевать регистрацию единого налога больше не нужно будет.
в качестве теста я грузил 1000 клиентов и 30 000 товаров, это давало 3 000 000 записей в таблице прайсов — скорость работы визуально такая же (SQLite очень быстр и запросы возвращающие данные для отображения в списке выполняются очень быстро), но это уже объемы которые не применимы для приложений данного типа
видимо, что за кучей технического описания вы пропустили одну из самых важных вещей о которой он (Кайт) говорит очень часто, а именно, что работая с к-л СУБД не нужно пытаться применить к ней знания полученные при работе с другими СУБД (речь сейчас не об sql-запросах). любая СУБД это прежде всего инструмент и чтобы им правильно воспользоваться нужно, как минимум, изучить его (типы индексов, блокировки и т.д. и т.п.). вы уцепились за планы приведенных мною запросов, но не хотите понять, что дело не в них, здесь вы совершенно верно объяснили почему один из запросов работает быстрее, но упорно не хотите понять, почему это ведет у скорению работы UI
ilichme, давайте уже завершим этот «пинг-понг» :) мы с Silver_Clash говорим о разных вещах я ему про ускорение работы интерфейса (объяснение которому он дал в своем же комментарии), а он мне про оптимизацию SQL-запросов — тему безусловно интересную, но выходящую за рамки этой статьи (о чем я написал, кстати, еще до ката)
возможно я не совсем правильно понял, но ведь ListView хранит в памяти, только строки видимые на экране? в нашем случае на экране помещалось примерно 7-10 строк
Ну подождите, в статье я привел описание где и для чего было применено это решение, ну при чем тут все то, что Вы начали мне предлагать? Ну Вы что-то знаете, где-то это применяли — отлично. Я не ставил своей целью поведать миру о «серебрянной пуле» я привел конкретное решение конкретной проблемы. Уверен, что есть еще много других способов решить эту проблему и кто-то сможет выбрать лучший для него вариант.
В нашем городе много рынков и очень часто ТА работают именно там, на рынке у них нет лишних 5 минут. А что делать в той ситуации, если ТА ушел от одного клиента к другому, начал уже вводить новый заказ, а тут звонит предыдущий клиент и просит что-то изменить в его заказе? Ждать 5 минут, а потом еще 5 минут, чтобы вернуться к незавершенному заказу 2-го клиента?
Можно наверное и xml использовать, но как быть, если не все клиенты работают с уникальными прайсами? Наша схема позволяет ряду клиентов назначить индивидуальные прайсы, ряду какие-то стандартные, а для ряда клиентов позволить ТА самому выбрать из разрешенного списка. И это все в одной простой схеме.
Если Вы внимательно прочтете, что написано в статье (без обид), то увидите, что приведенное решение очень, очень простое и оно не предлагает каких-то неизвестных вещей, а просто показывает как можно решить проблему минимальными усилиями.
Это Вы мне на дешевом смартфоне для тривиальной задачи его рекомендуете применить?
Может туда еще OLAP всунуть, полнотекстовый поиск и чтобы наверняка еще нейронную сеть? Да уж наверное люди работающие с этой программой даже не представляют какого счастья я их лишил.
Есть много вещей с которыми я тоже не работал или работал мало, но если Вы работаете с Oracle, то наверное знаете кто такой Том Кайт, так вот в своих книгах он пишет о том, что начиная работать с какой-то СУБД нужно изучить ее особенности, а не пытаться применить к ней знания полученные при работе с другими СУБД (я имею ввиду какие-то тонкости естественно, а не базовые принципы). В данном случае, описанный мной подход позволил получить заметный прирост в скорости работы UI, и для меня именно это имеет значение, а не то, что данный подход, возможно, не укладывается в какие-то принципы работы Oracle или другой СУБД, кроме того, если Вы внимательно почитаете статью и мои ответы на комментарии, то увидите, что я уже писал, что этот подход не стоит рассматривать для применения на десктопах/серверах и пр.
Какая структура? Для данного примера достаточно 3-х таблиц: товар, клиент, и прайс-листы.
Какая магия?
Запрос:
select p.Id, p.Name, p.Description, pp.PriceNal, pp.PriceBNal
from prod p
join prod_price pp on pp.prod_id = p.id
where pp.client_id = ?
будет выполняться дольше чем:
select p.Id
from prod p
join prod_price pp on pp.prod_id = p.id
where pp.client_id = ?
потому что, он возвращает меньше по объему данных (не строк). И на обработку такого запроса (при одиновых исходных условиях: наличие индексов и пр.) у SQLite уходит меньше времени чем на 1-й. Так при чем тут индексы? Вы хоть на все возвращаемые поля индексы навешайте. Повторяю еще раз: статья не про оптимизацию SQL-запросов, ну я уж не знаю как Вам это объяснить :)
И еще раз: речь идет не о десктопе, а о «маломощных» смартфонах, на десктопе Вы не заметите разницу в скорости (она будет очень несущественной).
Да я и не говорю, что планы запросов не меняются. Естественно все так как Вы написали. НО! Выполнение одного запроса, который возвращает все необходимые мне данные (для отображения в UI) происходит дольше, чем если я беру тот же запрос, но возвращающий одно поле, а остальные данные получаю потом. И хотя количество запросов к базе возрастает, общее время «отклика» интерфейса уменьшается.
Хочу еще раз обратить внимание: статья НЕ про оптимизацию SQL запросов и я даже постарался отметить это до хабраката.
ну все-таки разбиение процесса получения данных из БД не всегда себя обравдывает, да и как-то не встречалось мне подобное решение раньше, может плохо искал
Статья о том, что хороший план запроса в данном случае не помогал. Да, он выполнялся не минуты, секунды, но этого было недостаточно. Описанное решение позволило ускорить работу, не SQL запросов (они остались такими же, за исключением кол-ва возвращаемых данных), а конкретного интерфейса приложения в целом.
При выполнении запросов о которых идет речь разница во времени не очень большая, но в моем случае она все-же была (тестировалось на устройстве). Хотя полностью исключать вероятность ошибки не стоит, да и делалось все это более года назад, возможно уже новая версия SQLite вышла.
Q: You said that «and database project are also supported». So how can i do that?
A: Simply copy settings file to Database Project's root folder — and SqlCodeGuard addin will get settings from that file. Initial file can be found at %APPDATA%\SqlCodeGuard.Addin folder. Do not forget to include settings file in your source control so you'll be able to share yours settings with other team members.
Take a note that caption of «Select issue form» will contain name of project from which settings were taken or if settings were taken from addin's settings file.
Почему бы тоже самое не реализовать в хранимых процедурах? Мне кажется реализация «логики» в триггерах не самое хорошее решение, хотя может в случае небольшой, по кол-ву таблиц БД, оно и имеет смысл.
Кстати, начиная со следующего года продлевать регистрацию единого налога больше не нужно будет.
Так хоть скажите Кайта то читали? А-то совсем уж печально становится.
Можно наверное и xml использовать, но как быть, если не все клиенты работают с уникальными прайсами? Наша схема позволяет ряду клиентов назначить индивидуальные прайсы, ряду какие-то стандартные, а для ряда клиентов позволить ТА самому выбрать из разрешенного списка. И это все в одной простой схеме.
Если Вы внимательно прочтете, что написано в статье (без обид), то увидите, что приведенное решение очень, очень простое и оно не предлагает каких-то неизвестных вещей, а просто показывает как можно решить проблему минимальными усилиями.
Может туда еще OLAP всунуть, полнотекстовый поиск и чтобы наверняка еще нейронную сеть? Да уж наверное люди работающие с этой программой даже не представляют какого счастья я их лишил.
Для этого нужно прочесть статью.
Вы сравниваете запросы, которые выдают РАЗНЫЙ результат!
Я привел пример показывающий что позволяет получить ускорение работы интерфейса.
Какая магия?
Запрос:
будет выполняться дольше чем:
потому что, он возвращает меньше по объему данных (не строк). И на обработку такого запроса (при одиновых исходных условиях: наличие индексов и пр.) у SQLite уходит меньше времени чем на 1-й. Так при чем тут индексы? Вы хоть на все возвращаемые поля индексы навешайте. Повторяю еще раз: статья не про оптимизацию SQL-запросов, ну я уж не знаю как Вам это объяснить :)
И еще раз: речь идет не о десктопе, а о «маломощных» смартфонах, на десктопе Вы не заметите разницу в скорости (она будет очень несущественной).
Хочу еще раз обратить внимание: статья НЕ про оптимизацию SQL запросов и я даже постарался отметить это до хабраката.
Q: You said that «and database project are also supported». So how can i do that?
A: Simply copy settings file to Database Project's root folder — and SqlCodeGuard addin will get settings from that file. Initial file can be found at %APPDATA%\SqlCodeGuard.Addin folder. Do not forget to include settings file in your source control so you'll be able to share yours settings with other team members.
Take a note that caption of «Select issue form» will contain name of project from which settings were taken or if settings were taken from addin's settings file.