Да что ж такое… В третий раз и на те же грабли… Здесь просто поиск дубликатов, без ухищерений. Стандартное условное форматирование полностью подходит :facepalm
На сколько я понял идею автора, первое попадание за повторение не считается. Красным выделять второе и последующие попадения идентификатора.
берем каждую ячейку таблицы, и сравниваем ее со всеми ячейками, которые находятся после нее (стоит отметить, что в том столбце, где вхождение элемента встречается первый раз, повторений быть не может, поэтому мы начинаем сравнение со следующего столбца), и, если находим совпадения, красим их красным цветом.
И да. можно без сортировки:
Но не знаю как поведет себя на объемах.
А, если с сортировкой, то формула проще — достаточно сравнить с предыдущим значением и за объемы не страшно
Для того чтобы подкрасить совпадающие идентификаторы в экселе, наверное стоило бы в первую очередь отсортировать набор и настроить т.н. «условное форматирование».
Но, безусловно, это было бы куда менее творческое решение
он был переименован в PaintCAD по аналогии с AutoCAD, но никакой «автоматизации» помимо эффектов и обработок в нем нет.
Я так понял что значит auto — вы разобрались и поняли что здесь оно не уместно.
Осталось только разобраться с тем, что же такое Ссылка, и понять то же самое. ;)
ООП это прежде всего подход. Подход, при котором еденица воздействия — объект. Если мы попытаемся применить этот подход к обработке больших массивов данных, мы будем вынуждены работать не с множествами объектов, а с каждым объектом по отдельности.
ООП и БД — это абсолютно разные, непересекающиеся, друг от друга независимые вещи.
Абсолютно верно. Но в последнее время действительно имеется тенденция применения объектной парадигмы при работе и с реляционными данными. Многие фреймворки маскируют реляционный слой, предоставляя его ОО обертку. 1С — прекрасный тому пример.
Oracle строит индекс по 1 млн элементов за 20 секунд
Вы же понимаете, что это ооооочень сильно зависит от железа и нагрузки.
Вот мой тестовый сервак, здесь железо далеко не продуктивное: SQL> set timing on
SQL> create table test as select level val from dual connect by level <= 1e6;
Table created
Executed in 1.312 seconds
SQL> create index test$val$idx on test(val);
Index created
Executed in 0.75 seconds
И нельзя, нельзя сравнивать построение индекса и скорость сортировки. Индекс это построение сбалансированного двоичного дерева, цель которого — увеличение скорости доступа к данным. Это куда больше чем просто получение отсортированного набора данных. Если вы попытаетесь самостоятельно построить двоичное дерево, пусть и без сброса на диск, лишь в оперативе, я полагаю вам придется изрядно потрудиться, чтобы таки померяться с ораклом.
С вашим выводом я, в общем и целом, согласен, как и с некоторыми тезисами.
Применение парадигмы ООП действительно существенно увеличивает показатель запросов/секунду. Закрытие периода выполненное в традициях этого подхода, действительно заспамит базу данных запросами. В то же время можно и обойтись десятком — другим запросов, но это уже больше ближе к выносу логики на сторону сервера.
Однако подводка… действительно заставляет недоумевать.
Разумное зерно в вашей статье безусловно есть. Но оно далеко не на поверхности. И от него очень отвлекают спорно сформулированные тезисы и сферические цифры в вакууме.
Думаю, люди вас просто не поняли — очень подкачало изложение.
MySQL особым образом выполняет преобразование строки в число, эту особенность весьма ловко использовал автор в своем решении. Ссылку на демонстрацию этой особенности в документации он оставил в коментариях.
>> добавление такой таблицы — это денормализация базы, что не всегда есть хорошо. Делай хорошо, а плохо само получится!
Очень, очень спорный тезис.
Бездумная нормализация так же плоха как бездумная денормализация. В общем случае нельзя сказать что если структура соответствует xNF, то она хороша. Это расхожее заблуждение, вызванное следованиям практикам, без понимания причин, эти практики обуславливающих.
Нормализация предназначена лишь для упрощения контроля целостности данных — не более, не менее. Денормализация структуры усложняет этот контроль, требует предприятия дополнительного комплекса мер, но может в значительной степени увеличить эффективность использования.
Сразу оговорюсь, что даю вам не ответ, а лишь свои размышления.
Вы когда-нибудь слышали об крупных DWH, успешно реализованными под управлением MySQL? PG? Я лично — не особо. В новостной ленте постоянно всплывает информация об Oracle, MS SQL и DB2, а вот хранилища на PG,MySQL — не особо на слуху. Только сейчас, погуглив, я выяснил, что есть люди, которые задаются этим же вопросом, и что даже есть люди, которые им что-то отвечают.
Вы бы сами не побоялись под управлением этих СУБД консолидировать данные, скажем о продажах в пятиста крупных розничных магазинов в течении пяти последних лет, с целью получения аналитики вроде динамики изменения средней суммы чека, какой товар с каким чаще берут вместе, влияние сезонности на спрос по товару и многого, многого другого. Я, лично — очень струхнул бы. Предпочел бы проконсультироваться с вендором, поискать прецеденты. В случае с ораклом есть и именитый вендор, чье слово не стыдно «пришить к делу», на чье слово можно опереться, есть и множество прецедентов, которыми можно блеснуть в презентации перед акционерами. А в случае с тем же ПГ? На кого именитого сослаться, подкрепляя собственное решение?
Потому и получается, что когда мы говорим об DWH, выбор может пасть только на Оракл, MS, IBM и без всяких там откатов. Сеть изобилует сравнением решений для этих субд, на разных железных платформах, оставляя ощущение, что другие СУБД для этих целей просто никто не использует.
А дальше лишь вопрос лицензирования. Если уж мы приобретаем лицензию оракла для DWH, то зачем использовать что либо другое для всего прочего? Тонкостей лицензирования я не знаю, но у нас в конторе никто особо не напрягается разворачивая новую БД под oracle database для новых решений в продакшн. Вроде как тем самым мы лицензионное соглашение не нарушаем.
Первая же фраза под катом — «Честно говоря, не знаю» заставила почувствовать себя безнадежно обманутым, и чувство это не улетучилось и по прочтении всей статьи. (
Статья о том, что прежде чем задействовать арсенал свистелок на все случаи жизни, таки полезно ознакомиться с азами предметной области и таки решить тривиальную задачу тривиальным способом.
А то, что тривиальное решение преподносится как экстраординарное — да: c одной стороны умиляет, но с другой — заставляет недоумевать.
>>Как вариант
Да, это тоже вариант. И он у нас тоже применяется. На больших объемах. Однако ж если есть возможность предотвратить ошибку, лучше ее использовать. В результате рассогласования данных может произойти и потеря и искажение информации и не всегда восстановимые.
>>Циклические зависимости не есть хорошо. От них нельзя избавиться?
Теперь в этом убедился и заказчик, так что будем избавлятсья ))
>>крутая статья
Спасибо за крайне лестную оценку )
Vampiro, предложенное вами решение, судя по всему, помимо того что более простое, еще и подходящее.
И да. можно без сортировки:
Но не знаю как поведет себя на объемах.
А, если с сортировкой, то формула проще — достаточно сравнить с предыдущим значением и за объемы не страшно
Но, безусловно, это было бы куда менее творческое решение
Я так понял что значит auto — вы разобрались и поняли что здесь оно не уместно.
Осталось только разобраться с тем, что же такое Ссылка, и понять то же самое. ;)
ООП это прежде всего подход. Подход, при котором еденица воздействия — объект. Если мы попытаемся применить этот подход к обработке больших массивов данных, мы будем вынуждены работать не с множествами объектов, а с каждым объектом по отдельности.
Абсолютно верно. Но в последнее время действительно имеется тенденция применения объектной парадигмы при работе и с реляционными данными. Многие фреймворки маскируют реляционный слой, предоставляя его ОО обертку. 1С — прекрасный тому пример.
Вы же понимаете, что это ооооочень сильно зависит от железа и нагрузки.
Вот мой тестовый сервак, здесь железо далеко не продуктивное:
SQL> set timing on
SQL> create table test as select level val from dual connect by level <= 1e6;
Table created
Executed in 1.312 seconds
SQL> create index test$val$idx on test(val);
Index created
Executed in 0.75 seconds
И нельзя, нельзя сравнивать построение индекса и скорость сортировки. Индекс это построение сбалансированного двоичного дерева, цель которого — увеличение скорости доступа к данным. Это куда больше чем просто получение отсортированного набора данных. Если вы попытаетесь самостоятельно построить двоичное дерево, пусть и без сброса на диск, лишь в оперативе, я полагаю вам придется изрядно потрудиться, чтобы таки померяться с ораклом.
Применение парадигмы ООП действительно существенно увеличивает показатель запросов/секунду. Закрытие периода выполненное в традициях этого подхода, действительно заспамит базу данных запросами. В то же время можно и обойтись десятком — другим запросов, но это уже больше ближе к выносу логики на сторону сервера.
Однако подводка… действительно заставляет недоумевать.
Разумное зерно в вашей статье безусловно есть. Но оно далеко не на поверхности. И от него очень отвлекают спорно сформулированные тезисы и сферические цифры в вакууме.
Думаю, люди вас просто не поняли — очень подкачало изложение.
SQL> select to_number(regexp_substr('$1','\$[0-9]+')) from dualORA-01722: invalid number
На моей платформе данный подход неизбежно приводит к ORA-01722: invalid number
Очень, очень спорный тезис.
Бездумная нормализация так же плоха как бездумная денормализация. В общем случае нельзя сказать что если структура соответствует xNF, то она хороша. Это расхожее заблуждение, вызванное следованиям практикам, без понимания причин, эти практики обуславливающих.
Нормализация предназначена лишь для упрощения контроля целостности данных — не более, не менее. Денормализация структуры усложняет этот контроль, требует предприятия дополнительного комплекса мер, но может в значительной степени увеличить эффективность использования.
Вы когда-нибудь слышали об крупных DWH, успешно реализованными под управлением MySQL? PG? Я лично — не особо. В новостной ленте постоянно всплывает информация об Oracle, MS SQL и DB2, а вот хранилища на PG,MySQL — не особо на слуху. Только сейчас, погуглив, я выяснил, что есть люди, которые задаются этим же вопросом, и что даже есть люди, которые им что-то отвечают.
Вы бы сами не побоялись под управлением этих СУБД консолидировать данные, скажем о продажах в пятиста крупных розничных магазинов в течении пяти последних лет, с целью получения аналитики вроде динамики изменения средней суммы чека, какой товар с каким чаще берут вместе, влияние сезонности на спрос по товару и многого, многого другого. Я, лично — очень струхнул бы. Предпочел бы проконсультироваться с вендором, поискать прецеденты. В случае с ораклом есть и именитый вендор, чье слово не стыдно «пришить к делу», на чье слово можно опереться, есть и множество прецедентов, которыми можно блеснуть в презентации перед акционерами. А в случае с тем же ПГ? На кого именитого сослаться, подкрепляя собственное решение?
Потому и получается, что когда мы говорим об DWH, выбор может пасть только на Оракл, MS, IBM и без всяких там откатов. Сеть изобилует сравнением решений для этих субд, на разных железных платформах, оставляя ощущение, что другие СУБД для этих целей просто никто не использует.
А дальше лишь вопрос лицензирования. Если уж мы приобретаем лицензию оракла для DWH, то зачем использовать что либо другое для всего прочего? Тонкостей лицензирования я не знаю, но у нас в конторе никто особо не напрягается разворачивая новую БД под oracle database для новых решений в продакшн. Вроде как тем самым мы лицензионное соглашение не нарушаем.
А то, что тривиальное решение преподносится как экстраординарное — да: c одной стороны умиляет, но с другой — заставляет недоумевать.
Да, это тоже вариант. И он у нас тоже применяется. На больших объемах. Однако ж если есть возможность предотвратить ошибку, лучше ее использовать. В результате рассогласования данных может произойти и потеря и искажение информации и не всегда восстановимые.
>>Циклические зависимости не есть хорошо. От них нельзя избавиться?
Теперь в этом убедился и заказчик, так что будем избавлятсья ))
>>крутая статья
Спасибо за крайне лестную оценку )