Единственное, что не отражено в этих ответах, о которых я хотел бы упомянуть, это то, что это также зависит от того, как вы используете SQL. Возьмите arcpy, например. По какой-то причине ни одна из функций arcpy.da не имеет функции execute много. Это действительно странно, потому что почти все остальные библиотеки Python sql делают. Оператор Where в функциях arcpy.da также ограничен примерно 120 символами. По сути, это означает, что, если у вас есть относительно большое количество вещей, которые вы пытаетесь сделать с вашей базой данных, ваш единственный реальный выбор - вызывать выбранную вами функцию arcpy.da несколько раз, меняя оператор where каждый раз, когда вы делаете это. Есть несколько приемов, которые вы можете использовать, чтобы ускорить этот процесс - например, вы можете перебирать фрагменты вашего набора данных - но буквально каждый из этих приемов намного медленнее, чем просто использование одного arcpy.da. searchcursor для загрузки всей вашей таблицы во фрейм данных pandas, а затем манипулирования ею с использованием pandas, numpy, и, если ваши данные действительно такие большие, dask. Здесь я должен подчеркнуть, что в этом случае панды не просто немного быстрее. Это отвратительно быстрее. Это так быстро, что я буквально смеялся над собой за то, что не сделал этого раньше. Использование панд сократило время выполнения одного скрипта с более чем часа - я забыл, если это был скачок с 3,5 часов или с 1,5 часов - до буквально 12 минут. Это было так быстро, что я буквально смеялся над собой, потому что не сделал этого раньше. Использование панд сократило время выполнения одного скрипта с более чем часа - я забыл, если это был скачок с 3,5 часов или с 1,5 часов - до буквально 12 минут. Это было так быстро, что я буквально смеялся над собой, потому что не сделал этого раньше. Использование панд сократило время выполнения одного скрипта с более чем часа - я забыл, если это был скачок с 3,5 часов или с 1,5 часов - до буквально 12 минут.
Стоит отметить, что хотя я мог бы сделать это с помощью sql, мне потребовалось бы гораздо больше времени на изучение. Мне бы пришлось либо изучать операции специально для SQL в Access - вот где заканчивались данные для этого скрипта - SQL в Access был не так надежен, как мне было нужно, когда я действительно собирался это делать, или Мне пришлось бы записать все свои данные в базу данных sqlite3, манипулировать ими там, а затем поместить в Access. Хотя это могло дать мне аналогичные результаты производительности, в будущем мой сценарий было бы сложнее модифицировать.
Так что да, иногда Pandas и просто строго лучше, чем использовать опции sql, которые есть в вашем распоряжении . Все, что мне нужно было сделать в sql, было сделано с помощью функции в pandas. Вы также можете использовать синтаксис sql с пандами, если хотите. Есть небольшая причина не использовать панд и sql в тандеме.
Еще одна вещь, которую я хочу упомянуть о Pandas и numpy, заключается в том, что обе эти библиотеки по своей природе основаны на множестве подходов. Вы можете циклически проходить по фреймам данных и строить серии с помощью этих библиотек, но действительно трудно изменить данные в этих структурах таким образом, чтобы в итоге вы написали более эффективный код - на основе набора - с обеими этими библиотеками просто потому, что намного проще делать. «Руководствуясь», если не использовать методику, основанную на множестве, я не сталкивался с SQL.
Еще одна важная вещь, которую я забыл упомянуть с Пандами. Деньги . Pandas - это инструмент, который многие специалисты по науке о данных хотят, чтобы вы знали, как им пользоваться. Почти каждая работа по науке о данных, на которую я смотрел, платила больше, чем работа по управлению базами данных. Единственное исключение из этого, которое я заметил, - это Data Engineering, но я видел гораздо меньше таких вакансий. Панды, похоже, с первого взгляда приносят вам больше денег.