|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
19.08.2019, 15:50 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
Типичный хабаровский бред. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.08.2019, 16:11 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, гм, в разделе "Плохая оптимизация OR" - сначала он строит 4 странных композитных индекса, которые, как ему кажется, "должны работать" (вместо четырех одиночных по столбцам a, b, c, d), а потом удивляется, почему оптимизаторы "их не берут". ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2019, 00:57 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
kdvDimitry Sibiryakov, гм, в разделе "Плохая оптимизация OR" - сначала он строит 4 странных композитных индекса, которые, как ему кажется, "должны работать" (вместо четырех одиночных по столбцам a, b, c, d), а потом удивляется, почему оптимизаторы "их не берут". Чем четыре одиночных индекса по столбцам тут должны помочь? Вы же понимаете что найти a=5 AND b=6 при индексе по (a,b) можно гораздо быстрее, чем при двух индексах (a) и (b)? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2019, 09:37 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
Nitro_JunkiekdvDimitry Sibiryakov, гм, в разделе "Плохая оптимизация OR" - сначала он строит 4 странных композитных индекса, которые, как ему кажется, "должны работать" (вместо четырех одиночных по столбцам a, b, c, d), а потом удивляется, почему оптимизаторы "их не берут". Чем четыре одиночных индекса по столбцам тут должны помочь? Вы же понимаете что найти a=5 AND b=6 при индексе по (a,b) можно гораздо быстрее, чем при двух индексах (a) и (b)? Только его запрос не про это. Это передёргивание. Есть запрос и есть индексы, которые запрос не использует. А виноват сервер. Я думаю, программисты, занимающие планировщиком SQL-запросов сервера, делают всё возможное. Но человек, который создаёт схему данных и т.д., должен же себе отдавать отчёт, что он хочет. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2019, 10:08 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
KreatorXXINitro_Junkieпропущено... Чем четыре одиночных индекса по столбцам тут должны помочь? Вы же понимаете что найти a=5 AND b=6 при индексе по (a,b) можно гораздо быстрее, чем при двух индексах (a) и (b)? Только его запрос не про это. Это передёргивание. Есть запрос и есть индексы, которые запрос не использует. А виноват сервер. Я думаю, программисты, занимающие планировщиком SQL-запросов сервера, делают всё возможное. Но человек, который создаёт схему данных и т.д., должен же себе отдавать отчёт, что он хочет. Там достаточно простой тезис. SQL сервера выполняют логические условия как есть, не пытаясь особо их оптимизировать. То есть как и в остальных пунктах перекладывая задачу оптимизации на разработчика, тем самым повышая трудозатраты и порог вхождения. А заодно и риск выстрелить себе в ногу. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2019, 10:13 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
Nitro_Junkie, вовсе не обязательно. Они пытаются сделать всё что можно. З.Ы. Читал статью. Такое ощущение что автор старается сделать себе больно специально. Те кто понимают как работает конкретная СУБД никогда не будут писать так как описано в статье. Да это может сделать нечаянно некая ORM, но никак не вменяемый разработчик пишущий прямые SQL запросы. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2019, 11:59 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
Симонов ДенисNitro_Junkie, вовсе не обязательно. Они пытаются сделать всё что можно. З.Ы. Читал статью. Такое ощущение что автор старается сделать себе больно специально. Те кто понимают как работает конкретная СУБД никогда не будут писать так как описано в статье. Да это может сделать нечаянно некая ORM, но никак не вменяемый разработчик пишущий прямые SQL запросы. Так откуда разработчик должен знать что умеет оптимизировать конкретная СУБД или нет. Во-первых, это параметр изменяющийся во времени, а во-вторых, весь смысл оптимизаторов в том, чтобы не знать как они работают. Иначе нахрена они нужны, если я захочу все сделать руками, я сделаю это на ассемблере. Правда только совсем глупый работодатель это оплатит. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2019, 12:10 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
Nitro_JunkieВы же понимаете что найти a=5 AND b=6 при индексе по (a,b) можно гораздо быстрее, чем при двух индексах (a) и (b)? А Вы понимаете, что AND и OR это две очень большие разницы? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2019, 12:49 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
авторПри этом речь в статье пойдет не о «вкусах и цветах фломастеров». Все затрагиваемые проблемы носят фундаментальный характер: присутствуют при разработке практически любой информационной системы и не ограничиваются «красотой кода», а в той или иной степени приводят либо к критическому падению производительности, либо к существенному росту порога вхождения, либо к значительным трудозатратам со стороны разработчика.. ну, я я как то не дочитал, а там альтернатива, в которой фундаментальных проблем меньше, представлена? То есть не этих нет, а во всех отношениях лучше и удобнее? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2019, 12:56 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
Nitro_JunkieТак откуда разработчик должен знать что умеет оптимизировать конкретная СУБД или нет. Во-первых, это параметр изменяющийся во времени, а во-вторых, весь смысл оптимизаторов в том, чтобы не знать как они работают. Иначе нахрена они нужны, если я захочу все сделать руками, я сделаю это на ассемблере. Правда только совсем глупый работодатель это оплатит. Если это была попытка набросить на вентилятор - то Ок, принимается :-) А если сказано всерьез, то гнать такого разработчика нужно несвежими носками подальше от сервера СУБД. Во всяком случае от продуктивной среды. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2019, 13:48 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
Vladimir Baskakov, ну в статье явного указания на альтернативу нет, но если присмотреться, то они пиарят некий lsFusion ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2019, 13:54 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovNitro_JunkieВы же понимаете что найти a=5 AND b=6 при индексе по (a,b) можно гораздо быстрее, чем при двух индексах (a) и (b)? А Вы понимаете, что AND и OR это две очень большие разницы? К чему вы это? Там в разделе достаточно подробно расписано, как запрос надо оптимизировать, чтобы он быстро выполнялся. И там нужны именно индексы по двум полям, индексами по одному полю там никак не обойтись. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2019, 14:33 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
witteNitro_JunkieТак откуда разработчик должен знать что умеет оптимизировать конкретная СУБД или нет. Во-первых, это параметр изменяющийся во времени, а во-вторых, весь смысл оптимизаторов в том, чтобы не знать как они работают. Иначе нахрена они нужны, если я захочу все сделать руками, я сделаю это на ассемблере. Правда только совсем глупый работодатель это оплатит. Если это была попытка набросить на вентилятор - то Ок, принимается :-) А если сказано всерьез, то гнать такого разработчика нужно несвежими носками подальше от сервера СУБД. Во всяком случае от продуктивной среды. Где же вы столько "правильных" разработчиков найдете? Не, я понимаю если вы работаете по найму, дефицит разработчиков может быть выгоден, но если вы заказчик или подрядчик, все с точностью наоборот. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2019, 14:39 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovТипичный хабаровский бред. сказал человек с форума где 90% тем это "как мне правильно сделать Merge" ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2019, 15:40 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovТипичный хабаровский бред. Это же "Блог компании lsFusion", его пишут чтобы поднять статус компании, получить известность. Статья действительно ну...как бы бесполезная, не чтобы прочиьать, а чтобы НАПИСАТЬ. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2019, 16:34 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
БумбарашDimitry SibiryakovТипичный хабаровский бред. сказал человек с форума где 90% тем это "как мне правильно сделать Merge" Гы, он-то чем виноват, что он с этого форума? Дмитрий в общем -- хороший специалист, грамотный. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2019, 16:36 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
MasterZivон-то чем виноват, что он с этого форума? Меня больше заинтересовал вопрос какой именно из обитаемых мною форумов Бумбараш посчитал так, что 90% топиков получилось про Merge. bid 3?.. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2019, 16:45 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovMasterZivон-то чем виноват, что он с этого форума? Меня больше заинтересовал вопрос какой именно из обитаемых мною форумов Бумбараш посчитал так, что 90% топиков получилось про Merge. bid 3?.. Да ладно. Тут большую часть топиков почитаешь, так люди nested loop join от hash join'а не отличают, какой нафиг join predicate push down. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2019, 17:10 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
Nitro_JunkieТак откуда разработчик должен знать что умеет оптимизировать конкретная СУБД или нет. Во-первых, это параметр изменяющийся во времени, а во-вторых, весь смысл оптимизаторов в том, чтобы не знать как они работают. Иначе нахрена они нужны, если я захочу все сделать руками, я сделаю это на ассемблере. Правда только совсем глупый работодатель это оплатит. Если ты разрабатываешь под конкретную СУБД, то должен знать её хотя бы на среднем уровне. В конце концов запросы проверяются, можно посмотреть планы, переписать запросы, создать индексы и т.д. В целом ещё не было ни одного случая, чтобы не находилось решения которое устраивает по быстродействию. И кстати nested loop join это не всегда плохо. Если делаешь сразу под несколько СУБД что-то сложное, то скорее всего нормально не будет работать ни в одной. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2019, 21:57 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
Симонов ДенисИ кстати nested loop join это не всегда плохо. А вы, кстати, зачем это сказали? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2019, 00:57 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
Бумбараш, статью что читал? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2019, 06:50 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
Nitro_JunkieТак откуда разработчик должен знать что умеет оптимизировать конкретная СУБД или нет. Во-первых, это параметр изменяющийся во времени, а во-вторых, весь смысл оптимизаторов в том, чтобы не знать как они работают. Иначе нахрена они нужны, если я захочу все сделать руками, я сделаю это на ассемблере. Правда только совсем глупый работодатель это оплатит. В теме по MS SQL посоветовали материализацию count(*) на млрд записях, ранее заявленную как круто работающую, сделать в пару слегка неадекватных прыжков. Откуда разработчик должен знать о том, как работает данных фреймворк и что надо так глумиться над ним? И вооще, фреймворки/ОРМ - штука на порядок более распространенная ввиду того, что множество неосиливших SQL огромно и почти каждый из этого множества считает своим долгом запилить свой мегафреймворк для "вааще любой СУБД". А раз распространенная, значит и существенно чаще утилизируемая. А вот работодателю интересно подсадить работника на уникальный с минимальным количеством вакансий фреймворк, чтобы он потом не сбежал куда, где кормят лучше. Ибо нахрен не нужен спец, который хорошо знает что-то никому никуда не упирающееся... ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2019, 07:54 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
Симонов ДенисЕсли делаешь сразу под несколько СУБД что-то сложное, то скорее всего нормально не будет работать ни в одной. Вообще статья как раз про это, и про то как обходить проблемы, чтобы система нормально работала на всех СУБД. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2019, 08:48 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
andy stВ теме по MS SQL посоветовали материализацию count(*) на млрд записях, ранее заявленную как круто работающую, сделать в пару слегка неадекватных прыжков. Откуда разработчик должен знать о том, как работает данных фреймворк и что надо так глумиться над ним? Тут вообще-то не две крайности, все руками и все автоматически. Есть полутона. Хотя конечно если бы платформа сама умела разбивать материализации на неконкурентные, и вообще сама умела бы их создавать было бы гораздо круче. Но лучшее как известно враг хорошего. andy stА вот работодателю интересно подсадить работника на уникальный с минимальным количеством вакансий фреймворк, чтобы он потом не сбежал куда, где кормят лучше. Ибо нахрен не нужен спец, который хорошо знает что-то никому никуда не упирающееся... Я, например, за последние 5 лет работал с : 1. Groovy под Jenkins 2. Java - бэкенд, десктоп 3. JavaScript + React, Java + GWT - фронтенд 4. NSIS - инсталлятор 5. ANTLR, GrammarKit + IDEA - работа с языками интерпретаторы, IDE 6. PHP + October CMS - когда на сайт надо было подключить сложную функциональность, которую отдавать разработчикам сайтов себе дороже и явно упустил еще с пяток фреймворков и языков. Вообще в современном мире где пять лет назад никто не слышал про React и NoSQL, а технологии меняются раз в 3 года, умение разбираться в них по сути единственный важный навык программиста. И человек, который не умеет этого делать а сфокусирован на конкретных технологиях - херовый программист. Я например в резюме на предыдущий опыт вообще не смотрю, потому как хорошо знаю, что человек с мозгами вообще без опыта в технологии через 3 месяца может быть гораздо полезнее на проекте, чем человек с 10+ лет опыта, который не умеет систематизировать информацию и составлять общую картину. И бизнесу нужны люди умеющие решать проблемы, а не с длинным резюме. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2019, 08:58 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
Nitro_Junkieandy stВ теме по MS SQL посоветовали материализацию count(*) на млрд записях, ранее заявленную как круто работающую, сделать в пару слегка неадекватных прыжков. Откуда разработчик должен знать о том, как работает данных фреймворк и что надо так глумиться над ним? Тут вообще-то не две крайности, все руками и все автоматически. Есть полутона. Хотя конечно если бы платформа сама умела разбивать материализации на неконкурентные, и вообще сама умела бы их создавать было бы гораздо круче. Но лучшее как известно враг хорошего. Только не ляпните последнюю фразу гденить на презентации продукта или в статье на том же хабре - это первый звонок о том, что разрабы дошли до своего предела и дальше не хватает либо ресурсов, либо мозгов.Но, в любом случае, когда презенуют очередную "серебряную пулю" для "универсального мгновенного и экстраординарного улучшения" продуктов, в которые вложено на несколько порядков больше ресурсов возникает только одна мысль - подозрение. Подозрение, что впаривают дичь, что разработчики слегонца так "чрезмерно самоуверены" ну и т.п... Nitro_Junkieandy stА вот работодателю интересно подсадить работника на уникальный с минимальным количеством вакансий фреймворк, чтобы он потом не сбежал куда, где кормят лучше. Ибо нахрен не нужен спец, который хорошо знает что-то никому никуда не упирающееся... Я, например, за последние 5 лет работал с : 1. Groovy под Jenkins 2. Java - бэкенд, десктоп 3. JavaScript + React, Java + GWT - фронтенд 4. NSIS - инсталлятор 5. ANTLR, GrammarKit + IDEA - работа с языками интерпретаторы, IDE 6. PHP + October CMS - когда на сайт надо было подключить сложную функциональность, которую отдавать разработчикам сайтов себе дороже и явно упустил еще с пяток фреймворков и языков. Вообще в современном мире где пять лет назад никто не слышал про React и NoSQL, а технологии меняются раз в 3 года, умение разбираться в них по сути единственный важный навык программиста. И человек, который не умеет этого делать а сфокусирован на конкретных технологиях - херовый программист. Я например в резюме на предыдущий опыт вообще не смотрю, потому как хорошо знаю, что человек с мозгами вообще без опыта в технологии через 3 месяца может быть гораздо полезнее на проекте, чем человек с 10+ лет опыта, который не умеет систематизировать информацию и составлять общую картину. И бизнесу нужны люди умеющие решать проблемы, а не с длинным резюме. Помойму 5 пукнтов + еще "с пяток фреймворков" - это и есть немного длинное резюме? не? nosql было до sql *дцать лет назад, называл только каждый разработчик как хотел. То, что кучу разных технологий назвали одним словом несколько лет назад означает лишь то, что кто-то сумел приписать no к sql. Больше никаких заслуг тут нет. React - это очень частный случай в сфере разработки ПО и его знание в других случаях вообще никуда не упирается. а так: "я знаю каратэ. дзюдо, самбо и еще много других страшных слов" (с) не я. фтопку такого разраба. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2019, 09:54 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
andy stНо, в любом случае, когда презенуют очередную "серебряную пулю" для "универсального мгновенного и экстраординарного улучшения" продуктов, в которые вложено на несколько порядков больше ресурсов возникает только одна мысль - подозрение. Подозрение, что впаривают дичь, что разработчики слегонца так "чрезмерно самоуверены" ну и т.п... Ну вы же понимаете, что вложение ресурсов очень часто слабо коррелированно с результатом. То есть алгоритм со сложностью O(n) даже на моем компьютере обгонит алгоритм со сложностью O(n!) на суперкомпьютере. Или другими словами знание куда бежать важнее скорости бега. Хотя подозрение вполне нормальная реакция на все новое. Но как и у любой инновации есть две претензии: 1. Это уже было в продукте X. Тут все проще даже ничего проверять не надо, достаточно привести пример этого X. Но именно для этого на сайте сделано сравнение с существующими технологиями, и сейчас делаются дополнительные статьи (вот одна про SQL была). 2. Это не заработает. Вот тут сложнее, можно конечно предложить приехать на экскурсию, но мало кто согласится. В любом случае преодолеть это сомнение вопрос времени. andy stПомойму 5 пукнтов + еще "с пяток фреймворков" - это и есть немного длинное резюме? не? nosql было до sql *дцать лет назад, называл только каждый разработчик как хотел. То, что кучу разных технологий назвали одним словом несколько лет назад означает лишь то, что кто-то сумел приписать no к sql. Больше никаких заслуг тут нет. React - это очень частный случай в сфере разработки ПО и его знание в других случаях вообще никуда не упирается. а так: "я знаю каратэ. дзюдо, самбо и еще много других страшных слов" (с) не я. фтопку такого разраба. Еще раз, я сказал то что для настоящего разработчика технологии это не более чем инструмент. Его мозги куда важнее. Если они есть , разработчик сможет пользоваться любым инструментом. И экскаватором, даже если он никогда его в глаза не видел, выкопает яму быстрее чем лопатой. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2019, 10:09 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
Nitro_Junkieandy stНо, в любом случае, когда презенуют очередную "серебряную пулю" для "универсального мгновенного и экстраординарного улучшения" продуктов, в которые вложено на несколько порядков больше ресурсов возникает только одна мысль - подозрение. Подозрение, что впаривают дичь, что разработчики слегонца так "чрезмерно самоуверены" ну и т.п... Ну вы же понимаете, что вложение ресурсов очень часто слабо коррелированно с результатом. То есть алгоритм со сложностью O(n) даже на моем компьютере обгонит алгоритм со сложностью O(n!) на суперкомпьютере. Или другими словами знание куда бежать важнее скорости бега. Вообще не понимаю. Не путайте плз вычислительные ресурсы - аналог ресурса кодировщиков уровня говнокода, и интеллектуальные. Суперкомп может за затратить время на анализ и выбор аналогичного алгоритма с O(1). Тогда ваш комп убудет в дупу. Думаю, людей, "знающих куда бежать" в том же MS или Oracle существенно больше и "знают" они существенно лучше. Nitro_JunkieХотя подозрение вполне нормальная реакция на все новое. Но как и у любой инновации есть две претензии: 1. Это уже было в продукте X. Тут все проще даже ничего проверять не надо, достаточно привести пример этого X. Но именно для этого на сайте сделано сравнение с существующими технологиями, и сейчас делаются дополнительные статьи (вот одна про SQL была). 2. Это не заработает. Вот тут сложнее, можно конечно предложить приехать на экскурсию, но мало кто согласится. В любом случае преодолеть это сомнение вопрос времени. Нужно найти жертву для success story, запилить там реальный проект (желательно чуть толще, чем "АРМ продавца билетов в туалет") и уж тогда что-то писать на техническом ресурсе. Точнее не что-то, а описать проект, его объемы, процесс внедрения, эффект от внедрения. А пока единственный шанс это впарить - найти не совсем вменяемого топа, у которого подчиненные не смогут обосновать нецелесообразность внедрения этого продукта :) А потом молиться, чтобы не подсунули проект, который реализовать на продукте будет либо очень сложно, либо вообще невозможно. Nitro_Junkieandy stПомойму 5 пукнтов + еще "с пяток фреймворков" - это и есть немного длинное резюме? не? nosql было до sql *дцать лет назад, называл только каждый разработчик как хотел. То, что кучу разных технологий назвали одним словом несколько лет назад означает лишь то, что кто-то сумел приписать no к sql. Больше никаких заслуг тут нет. React - это очень частный случай в сфере разработки ПО и его знание в других случаях вообще никуда не упирается. а так: "я знаю каратэ. дзюдо, самбо и еще много других страшных слов" (с) не я. фтопку такого разраба. Еще раз, я сказал то что для настоящего разработчика технологии это не более чем инструмент. Его мозги куда важнее. Если они есть , разработчик сможет пользоваться любым инструментом. И экскаватором, даже если он никогда его в глаза не видел, выкопает яму быстрее чем лопатой. мозги важнее, но не показатель "знаю много страшных слов", т.е. пробежался по 100500 технологиям по верхам и стал мегаспецом. ps.: запаришся копать экскаватором, если ни разу до этого за рычагами не сидел. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2019, 10:41 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
Nitro_Junkie И там нужны именно индексы по двум полям, индексами по одному полю там никак не обойтись. гм, вот это поворот! А оптимизатор Firebird прекрасно с этим справляется. Если есть 4 одиночных индекса, то он просто строит битовые маски по каждому условию, а затем склеивает их теми самыми битовыми операциями запроса. И работает, это, прости господи, уже лет 25 точно. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2019, 10:53 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
andy stВообще не понимаю. Не путайте плз вычислительные ресурсы - аналог ресурса кодировщиков уровня говнокода, и интеллектуальные. Суперкомп может за затратить время на анализ и выбор аналогичного алгоритма с O(1). Тогда ваш комп убудет в дупу. Думаю, людей, "знающих куда бежать" в том же MS или Oracle существенно больше и "знают" они существенно лучше. Это очень наивное представление. Если бы так было, никаких Гуглов, Фейсбуков, Эпплов, Тесел и т.п. не существовало бы. Собственно весь смысл крупных компаний в том чтобы не изобретать ничего, а ждать пока это кто-то другой сделает и покупать (если конечно рост не будет такой стремительный что это не получится) andy stНужно найти жертву для success story, запилить там реальный проект (желательно чуть толще, чем "АРМ продавца билетов в туалет") и уж тогда что-то писать на техническом ресурсе. Точнее не что-то, а описать проект, его объемы, процесс внедрения, эффект от внедрения. А пока единственный шанс это впарить - найти не совсем вменяемого топа, у которого подчиненные не смогут обосновать нецелесообразность внедрения этого продукта :) А потом молиться, чтобы не подсунули проект, который реализовать на продукте будет либо очень сложно, либо вообще невозможно. Вы наверное комменты к статям не читали и даже не гуглили. Мы уже подмяли под себя больше половину крупной розницы в Беларуси, и сейчас начинаем на российский рынок выходить. И на lsFusion уже больше 40 проектов, в том числе в России (некоторые достаточно публичные и их нельзя называть без согласования с их ИТ). Причем большинство этих проектов с более чем 500 одновременных пользователей и террабайтными базами (в которых, например, все чеки с детализацией онлайн сразу с распределением по партиям принимаются и это на паре серверов стоимостью 10к максимум). Собственно проектов всего 40 потому как с мелочевкой как 1С пока предпочитаем не связываться, но зато стараемся брать проекты из разных областей (от ERP до BPM и ECM) andy stмозги важнее, но не показатель "знаю много страшных слов", т.е. пробежался по 100500 технологиям по верхам и стал мегаспецом. ps.: запаришся копать экскаватором, если ни разу до этого за рычагами не сидел. Вы передергиваете. Я как раз и говорю что знание технологий - пыль. Умение думать makes difference. Ну если вы не умеете учиться - то да запаришься. А если есть мозги, то можно легко обучиться чему угодно . ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2019, 10:54 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
kdvNitro_Junkie И там нужны именно индексы по двум полям, индексами по одному полю там никак не обойтись. гм, вот это поворот! А оптимизатор Firebird прекрасно с этим справляется. Если есть 4 одиночных индекса, то он просто строит битовые маски по каждому условию, а затем склеивает их теми самыми битовыми операциями запроса. И работает, это, прости господи, уже лет 25 точно. Не поверите, но ms sql и oracle это тоже делают, но это все равно на порядок медленнее, чем использовать индексы по двум полям (см. статью). ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2019, 11:00 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
Nitro_Junkieandy stВообще не понимаю. Не путайте плз вычислительные ресурсы - аналог ресурса кодировщиков уровня говнокода, и интеллектуальные. Суперкомп может за затратить время на анализ и выбор аналогичного алгоритма с O(1). Тогда ваш комп убудет в дупу. Думаю, людей, "знающих куда бежать" в том же MS или Oracle существенно больше и "знают" они существенно лучше. Это очень наивное представление. Если бы так было, никаких Гуглов, Фейсбуков, Эпплов, Тесел и т.п. не существовало бы. Собственно весь смысл крупных компаний в том чтобы не изобретать ничего, а ждать пока это кто-то другой сделает и покупать (если конечно рост не будет такой стремительный что это не получится) "Знают" они однозначно лучше. Иначе бы вы свою субд запилили, с блекджеком и т.п. И язык программирования свой тоже... Ну и ждем, когда вас купят MS. Ну или вы купите MS... Nitro_Junkieandy stНужно найти жертву для success story, запилить там реальный проект (желательно чуть толще, чем "АРМ продавца билетов в туалет") и уж тогда что-то писать на техническом ресурсе. Точнее не что-то, а описать проект, его объемы, процесс внедрения, эффект от внедрения. А пока единственный шанс это впарить - найти не совсем вменяемого топа, у которого подчиненные не смогут обосновать нецелесообразность внедрения этого продукта :) А потом молиться, чтобы не подсунули проект, который реализовать на продукте будет либо очень сложно, либо вообще невозможно. Вы наверное комменты к статям не читали и даже не гуглили. Мы уже подмяли под себя больше половину крупной розницы в Беларуси, и сейчас начинаем на российский рынок выходить. И на lsFusion уже больше 40 проектов, в том числе в России (некоторые достаточно публичные и их нельзя называть без согласования с их ИТ). Причем большинство этих проектов с более чем 500 одновременных пользователей и террабайтными базами (в которых, например, все чеки с детализацией онлайн сразу с распределением по партиям принимаются и это на паре серверов стоимостью 10к максимум). Собственно проектов всего 40 потому как с мелочевкой как 1С пока предпочитаем не связываться, но зато стараемся брать проекты из разных областей (от ERP до BPM и ECM) а хде финики? в смысле то, что я там выше написал: описание проекта и т.п... и хреново видать с розницей в Беларуси, что 40+ проектов - это половина рынка. 1С - мелочевка... ERP на ММК пилят... суровые у вас масштабы. Основные конкуренты, я так понимаю - SAP ? А комменты читать на хабре - чур меня, не заставите в эту канализацию нырять. Nitro_Junkieandy stмозги важнее, но не показатель "знаю много страшных слов", т.е. пробежался по 100500 технологиям по верхам и стал мегаспецом. ps.: запаришся копать экскаватором, если ни разу до этого за рычагами не сидел. Вы передергиваете. Я как раз и говорю что знание технологий - пыль. Умение думать makes difference. Ну если вы не умеете учиться - то да запаришься. А если есть мозги, то можно легко обучиться чему угодно . если вы все такие умные, то почему строем не ходите (с) не я термин "легко обучиться" больше подходит как раз для "копать лопатой, не копать лопатой" чему-то более серьезному легко не обучиться и с мегамозгом. Хотя копать ковшем экскаватора, как лопатой в рамках "побыстрому обучился" тоже можно... тяжко только. И хреновый результат. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2019, 11:19 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
Nitro_Junkie но это все равно на порядок медленнее, чем использовать индексы по двум полям никакого "порядка" в разнице производительности здесь не будет. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2019, 11:34 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
andy st"Знают" они однозначно лучше. Иначе бы вы свою субд запилили, с блекджеком и т.п. И язык программирования свой тоже... Точно также как Microsoft запилил бы свой поисковик, Google свою соцсеть, Facebook свой инстаграм, Фольксваген свой электромобиль и так далее. andy stв смысле то, что я там выше написал: описание проекта и т.п... А что вы там хотите увидеть? Я собственно уже написал про параметры. Описание технологии и сравнение - на сайте / хабре. Сделали быстро / бесшовно / под заказчика людьми без опыта в IT (кроме одного). andy stи хреново видать с розницей в Беларуси, что 40+ проектов - это половина рынка. Я специально уточнил крупной розницей. То есть топ-30 сетей. andy st1С - мелочевка... ERP на ММК пилят... суровые у вас масштабы. Основные конкуренты, я так понимаю - SAP ? Я не писал, что 1С не связывается с крупняками, я писал, что он связывается с мелочевкой. SAP нам такой же конкурент, как фольксваген эмбраеру, у нас фундаментально разные технологии. Хотя да мы оба "перевозим людей из точки А в точку Б". andy stА комменты читать на хабре - чур меня, не заставите в эту канализацию нырять. А здесь прямо сплошные интеллигенты и ни одного тролля. andy stесли вы все такие умные, то почему строем не ходите (с) не я термин "легко обучиться" больше подходит как раз для "копать лопатой, не копать лопатой" чему-то более серьезному легко не обучиться и с мегамозгом. Хотя копать ковшем экскаватора, как лопатой в рамках "побыстрому обучился" тоже можно... тяжко только. И хреновый результат. Ну я например легко обучаюсь, сверху приводил список недавних языков / технологий. Скажут завтра еще одну освою за пару дней, а через пару месяцев буду использовать ее эффективнее, чем человек с 10 летним опытом, но с ограниченными умственными способностями / кругозором. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2019, 14:08 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
kdvNitro_Junkie но это все равно на порядок медленнее, чем использовать индексы по двум полям никакого "порядка" в разнице производительности здесь не будет. Будет. Проверено. Собственно вам в примере из статьи надо будет пробежаться по 100к записям, а с двумя индексами по 1к записям. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2019, 14:09 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
Nitro_Junkieandy stв смысле то, что я там выше написал: описание проекта и т.п... А что вы там хотите увидеть? Я собственно уже написал про параметры. Описание технологии и сравнение - на сайте / хабре. Сделали быстро / бесшовно / под заказчика людьми без опыта в IT (кроме одного). Что было, что стало, какие затраты времени/денег. Технические подробности систем. Восхищенные отзывы пользователей... и всё в статье тут или на том же хабре. Дабы можно было проникнуться величием. "..людьми без опыта в IT..." уже проходили. купил фотоаппарат - фотограф, купил лопату - строитель, купил скальпель - хирург... с соотв. последствиями. Nitro_Junkieandy stА комменты читать на хабре - чур меня, не заставите в эту канализацию нырять. А здесь прямо сплошные интеллигенты и ни одного тролля. контингент адекватнее Nitro_Junkieandy stесли вы все такие умные, то почему строем не ходите (с) не я термин "легко обучиться" больше подходит как раз для "копать лопатой, не копать лопатой" чему-то более серьезному легко не обучиться и с мегамозгом. Хотя копать ковшем экскаватора, как лопатой в рамках "побыстрому обучился" тоже можно... тяжко только. И хреновый результат. Ну я например легко обучаюсь, сверху приводил список недавних языков / технологий. Скажут завтра еще одну освою за пару дней, а через пару месяцев буду использовать ее эффективнее, чем человек с 10 летним опытом, но с ограниченными умственными способностями / кругозором. наверно хорошо быть таким оптимистом, но в данном случае "можно нинада"? слишком дохрена уже таких "...завтра еще одну освою за пару дней, а через пару месяцев буду использовать ее эффективнее...", которых через 2.5 месяца просят свалить, ибо кругозором работу делать сложно, а серьезных знаний не насобиралось. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2019, 15:00 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
andy stЧто было, что стало, какие затраты времени/денег. Технические подробности систем. Восхищенные отзывы пользователей... и всё в статье тут или на том же хабре. Дабы можно было проникнуться величием. А вы поверите? Такого маркетинг буллшита каждый вендор тоннами генерит. Эффект гербалайф, как я его называю. andy st"..людьми без опыта в IT..." уже проходили. купил фотоаппарат - фотограф, купил лопату - строитель, купил скальпель - хирург... с соотв. последствиями. Ну все вроде работает, по несколько задач в день закрывается этими же людьми в FMCG рознице с глубиной автоматизации - глубже некуда. Но вы же все равно не поверите. andy stконтингент адекватнее Да прям таки. Особенно по второму комменту темы заметно. andy stслишком дохрена уже таких "...завтра еще одну освою за пару дней, а через пару месяцев буду использовать ее эффективнее...", которых через 2.5 месяца просят свалить, ибо кругозором работу делать сложно, а серьезных знаний не насобиралось. Ну или платформа делает все за вас. В любом случае пока проблем таких не возникало. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2019, 15:35 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
Nitro_Junkieandy stЧто было, что стало, какие затраты времени/денег. Технические подробности систем. Восхищенные отзывы пользователей... и всё в статье тут или на том же хабре. Дабы можно было проникнуться величием. А вы поверите? Такого маркетинг буллшита каждый вендор тоннами генерит. Эффект гербалайф, как я его называю. А такого и не надо. Надо технические подробности. Типа: крутилось на фокспро, сервер на pentium 2, 1 гиг памяти. Всё работало чётко, но мы качественно обработали барина и запустили аналог на ..., сервер на xeon phi 7210... на пиках тормозит... :) Было, проблемы, причины, принятое решение, обоснование, внедрение, результаты. И без рукалицо-буллшита, как в сравнениях на сайте, и чтобы было читать приятно. Nitro_Junkieandy st"..людьми без опыта в IT..." уже проходили. купил фотоаппарат - фотограф, купил лопату - строитель, купил скальпель - хирург... с соотв. последствиями. Ну все вроде работает, по несколько задач в день закрывается этими же людьми в FMCG рознице с глубиной автоматизации - глубже некуда. Но вы же все равно не поверите. Пишите статью, подумаю. Пока выглядит как очередная наколенная поделка с претензией на мировое господство. Nitro_Junkieandy stконтингент адекватнее Да прям таки. Особенно по второму комменту темы заметно. Есть такой хабр-эффект, а есть еще антихабр-эффект. Это - второе. Nitro_Junkieandy stслишком дохрена уже таких "...завтра еще одну освою за пару дней, а через пару месяцев буду использовать ее эффективнее...", которых через 2.5 месяца просят свалить, ибо кругозором работу делать сложно, а серьезных знаний не насобиралось. Ну или платформа делает все за вас. В любом случае пока проблем таких не возникало. С ростом сложности проектов будет всё сложнее и сложнее убеждать заказчика в ненужности различных фишек, которые он где-то видел и хотел бы видеть у себя. А как быть, если платформу такое делать не научили заранее... ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2019, 16:11 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
Nitro_JunkieБудет. Проверено. Собственно вам в примере из статьи надо будет пробежаться по 100к записям, а с двумя индексами по 1к записям. я проверил. Firebird 3. При абсолютном соответствии тесту, оптимизатор взял индексы только AD и BD, точно так же как PostgreSQL. Select Expression -> Aggregate -> Filter -> Table "MYTABLE" Access By ID -> Bitmap Or -> Bitmap -> Index "AD" Range Scan (partial match: 1/2) -> Bitmap -> Index "BD" Range Scan (partial match: 1/2) Execute time = 1s 420ms Reads from disk to cache = 128 438 Fetches from cache = 327 305 Выполним запрос, который "ДНФ": Тут да, план использует все 4 индекса Select Expression -> Aggregate -> Filter -> Table "MYTABLE" Access By ID -> Bitmap Or -> Bitmap Or -> Bitmap Or -> Bitmap -> Index "AC" Range Scan (full match) -> Bitmap -> Index "BC" Range Scan (full match) -> Bitmap -> Index "AD" Range Scan (full match) -> Bitmap -> Index "BD" Range Scan (full match) Execute time = 47ms Reads from disk to cache = 4 084 Fetches from cache = 7 731 Быстрее? Намного! Однако, запрос "прикручен" к использованию этих самых композитных индексов. Теперь убираем эти 4 композитных индекса, и строим 4 отдельных индекса по каждому столбцу (по 1 столбцу). Типа "create index bya on mytable(a)" ... План первого запроса Select Expression -> Aggregate -> Filter -> Table "MYTABLE" Access By ID -> Bitmap And -> Bitmap Or -> Bitmap -> Index "BYA" Range Scan (full match) -> Bitmap -> Index "BYB" Range Scan (full match) -> Bitmap Or -> Bitmap -> Index "BYC" Range Scan (full match) -> Bitmap -> Index "BYD" Range Scan (full match) Результат: Execute time = 109ms Reads from disk to cache = 4 575 Fetches from cache = 8 222 Запрос ДНФ, с такими индексами использует некоторые индексы лишний раз Select Expression -> Aggregate -> Filter -> Table "MYTABLE" Access By ID -> Bitmap Or -> Bitmap Or -> Bitmap Or -> Bitmap And -> Bitmap -> Index "BYC" Range Scan (full match) -> Bitmap -> Index "BYA" Range Scan (full match) -> Bitmap And -> Bitmap -> Index "BYC" Range Scan (full match) -> Bitmap -> Index "BYB" Range Scan (full match) -> Bitmap And -> Bitmap -> Index "BYD" Range Scan (full match) -> Bitmap -> Index "BYA" Range Scan (full match) -> Bitmap And -> Bitmap -> Index "BYD" Range Scan (full match) -> Bitmap -> Index "BYB" Range Scan (full match) Execute time = 141ms Reads from disk to cache = 4 575 Fetches from cache = 8 775 получилось на 41% дольше, чем исходный запрос (понятно почему, лишние битмапы и их слияние). Я напомню ваше высказывание: "но это все равно на порядок медленнее, чем использовать индексы по двум полям" Получается наоборот - 4 отдельных индекса по одиночным столбцам - на порядок быстрее чем 2 индекса по двум полям, и в 2 раза медленнее чем 4 индекса по двум полям при весьма выкрученом запросе (ДНФ). Так что в общем случае надо бы строить именно 4 отдельных одиночных индекса (и не крутить запрос), а не 4 композита, как привиделось автору статьи. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2019, 13:51 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
У вас как-то очень малая разница в reads / fetches. Тока что еще раз протестил на PostgreSQL с одиночными индексами: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27.
С двойными индексами: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23.
Разница 10 раз, а план точно такой же как в Firebird. И разница в Buffers и actual rows адекватная. Вы точно на тех же данных тестировали? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2019, 14:15 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
kdv, Хотя тут скорее вопрос почему у вас Firebird на ДНФ запросе так тупит. А можно более детальный план? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2019, 14:20 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
Nitro_Junkie, в тесте было 10млн записей, так? Я ошибся на -1 запись, думаю это несущественно. У базы размер страницы 4к, кэш 2048 страниц, данные таблицы: MYTABLE (139) Primary pointer page: 336, Index root page: 337 Total formats: 1, used formats: 1 Average record length: 41.87, total records: 9999999 Average version length: 0.00, total versions: 0, max versions: 0 Average fragment length: 0.00, total fragments: 0, max fragments: 0 Average unpacked length: 426.00, compression ratio: 10.17 Pointer pages: 253, data page slots: 204064 Data pages: 204064, average fill: 71% Primary pages: 204064, secondary pages: 0, swept pages: 0 Empty pages: 3, full pages: 204060 Fill distribution: 0 - 19% = 3 20 - 39% = 0 40 - 59% = 1 60 - 79% = 204060 80 - 99% = 0 Я не знаю, почему у PG на одиночных индексах настолько хуже. У ФБ разница в 2 раза (между обычным запросом и одиночными индексами и ДНФ запросом с композитами). ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2019, 14:25 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
kdvNitro_Junkie, в тесте было 10млн записей, так? Я ошибся на -1 запись, думаю это несущественно. У базы размер страницы 4к, кэш 2048 страниц, данные таблицы: MYTABLE (139) Primary pointer page: 336, Index root page: 337 Total formats: 1, used formats: 1 Average record length: 41.87, total records: 9999999 Average version length: 0.00, total versions: 0, max versions: 0 Average fragment length: 0.00, total fragments: 0, max fragments: 0 Average unpacked length: 426.00, compression ratio: 10.17 Pointer pages: 253, data page slots: 204064 Data pages: 204064, average fill: 71% Primary pages: 204064, secondary pages: 0, swept pages: 0 Empty pages: 3, full pages: 204060 Fill distribution: 0 - 19% = 3 20 - 39% = 0 40 - 59% = 1 60 - 79% = 204060 80 - 99% = 0 Я не знаю, почему у PG на одиночных индексах настолько хуже. У ФБ разница в 2 раза (между обычным запросом и одиночными индексами и ДНФ запросом с композитами). У PG на одиночных индексах как раз также как у Firebird. Вопрос почему у Firebird так тупит на двойных индексов (45 мс вместо 8мс у postgres). Собственно в плане PG видно, что сами записи он находит за 0.8мс против 78мс с одиночными индексами. Но так как ему еще нужно достать данные, накидывается 12 мс. И разница становится всего 10 раз (иначе было бы 100 раз). На самом деле если уменьшить выборку , чтобы в результате было не 1000 а 10 записей (и СУБД перейдет на Index scan) или замедлить диск разница по идее будет еще больше. Сейчас проверю. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2019, 14:44 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
Nitro_Junkie, Собственно да, если увеличить количество разновидностей в 10 раз (в скрипте генерации вместо *100, написать *1000), разница становится еще ощутимее: Одиночные индексы. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27.
Двойные индексы: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23.
То есть в 32 раза разница. А в Firebird есть планы по каждой вершине с количеством рядов и временем выполнения? Можете сюда скинуть? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2019, 15:04 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
Nitro_JunkieА в Firebird есть планы по каждой вершине с количеством рядов и временем выполнения? нет такого (некоторые цифры для плана есть только в тестовых сборках). и гистограмм в индексах тоже нет. Кроме того, в ИБ и ФБ план вычисляется только на этапе prepare, до выполнения запроса. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.08.2019, 00:57 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
Nitro_JunkieСимонов ДенисЕсли делаешь сразу под несколько СУБД что-то сложное, то скорее всего нормально не будет работать ни в одной. Вообще статья как раз про это, и про то как обходить проблемы, чтобы система нормально работала на всех СУБД.Только при этом она работает только поверх Постгрес.... ... |
|||
:
Нравится:
Не нравится:
|
|||
28.08.2019, 00:54 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
SiemarglNitro_Junkieпропущено... Вообще статья как раз про это, и про то как обходить проблемы, чтобы система нормально работала на всех СУБД.Только при этом она работает только поверх Постгрес.... Нет, там есть адаптеры и под MS SQL и под Oracle. Но пока только в коммерческой версии. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.08.2019, 08:49 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
Nitro_Junkie Вообще в современном мире где пять лет назад никто не слышал про React и NoSQL, а технологии меняются раз в 3 года, умение разбираться в них по сути единственный важный навык программиста. И человек, который не умеет этого делать а сфокусирован на конкретных технологиях - херовый программист. Я например в резюме на предыдущий опыт вообще не смотрю, потому как хорошо знаю, что человек с мозгами вообще без опыта в технологии через 3 месяца может быть гораздо полезнее на проекте, чем человек с 10+ лет опыта, который не умеет систематизировать информацию и составлять общую картину. И бизнесу нужны люди умеющие решать проблемы, а не с длинным резюме . т.е. не смотрим ни на опыт, ни на знания, а только в глаза - видим мозг и понимаем, что "этот решит" ... |
|||
:
Нравится:
Не нравится:
|
|||
02.09.2019, 10:43 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
Ролг ХупинNitro_JunkieВообще в современном мире где пять лет назад никто не слышал про React и NoSQL, а технологии меняются раз в 3 года, умение разбираться в них по сути единственный важный навык программиста. И человек, который не умеет этого делать а сфокусирован на конкретных технологиях - херовый программист. Я например в резюме на предыдущий опыт вообще не смотрю, потому как хорошо знаю, что человек с мозгами вообще без опыта в технологии через 3 месяца может быть гораздо полезнее на проекте, чем человек с 10+ лет опыта, который не умеет систематизировать информацию и составлять общую картину. И бизнесу нужны люди умеющие решать проблемы, а не с длинным резюме . т.е. не смотрим ни на опыт, ни на знания, а только в глаза - видим мозг и понимаем, что "этот решит" Ну не совсем в глаза, все-таки общение, тестовые задания и т.п. Но вообще в те же гуглы / фейсбуки также набирают, там всем наплевать на опыт и знания, не бодишоп же. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.09.2019, 11:50 |
|
Интересный взгляд на проблему сравнения
|
|||
---|---|---|---|
#18+
Nitro_JunkieРолг Хупинпропущено... т.е. не смотрим ни на опыт, ни на знания, а только в глаза - видим мозг и понимаем, что "этот решит" Ну не совсем в глаза, все-таки общение, тестовые задания и т.п. Но вообще в те же гуглы / фейсбуки также набирают, там всем наплевать на опыт и знания, не бодишоп же. данунах... не чудите, нас могут читать молодые девелоперы с подвижной психикой ... |
|||
:
Нравится:
Не нравится:
|
|||
17.09.2019, 16:43 |
|
|
start [/forum/topic.php?all=1&fid=35&tid=1552191]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
23ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
76ms |
get tp. blocked users: |
2ms |
others: | 238ms |
total: | 378ms |
0 / 0 |