СОЕДИНЕНИЕ SQL: НА по сравнению с равняется
Прежде всего, ваш json недействителен,
Я сделал правильный json из рассматриваемого, как показано ниже,
{
"context":[
{
"local":
[
{
"interface": "BDI200",
"desc":"eNODEB"
},
{
"interface": "BDI100",
"desc":"eNODEB"
}
]
},
{
"CPM": [
{
"interface": "BDI200",
"desc":"eNODEB"
},
{
"interface": "BDI100",
"desc":"eNODEB"
}
]
}
]
}
, если вы хотите перебрать этот json и получить все локальные, CPM и т. д. попробуйте это,
import json
a=open('4.txt','r')
data=json.load(a)
for k in data:
for j in data[k]:
d = j
for l in d:
print(l)
print(d[l])
7 ответов
Нет никакого различия, но удобочитаемость второго намного лучше, когда у Вас есть большой запрос мультисоединения с дополнительным где пункты для фильтрации.
Разделение пунктов соединения и пунктов фильтра является Хорошей Вещью :)
Первый - синтаксис ANSI 89, последний является ANSI 92.
Для того определенного запроса нет никакого различия. Однако с первым Вы теряете способность разделить фильтр от условия объединения в сложных запросах, и синтаксис для определения ОСТАВЛЕННЫЙ по сравнению с прямо по сравнению с ВНУТРЕННИМ часто сбивает с толку, особенно если необходимо пойти назад и вперед между различными поставщиками дб. Мне не нравится более старый синтаксис вообще.
Пока можно выполнить большинство задач с помощью обоих и в случае нет никакого различия вообще, я буду всегда использовать второе в любом случае.
- Это - текущий поддерживаемый стандарт
- Это сохраняет, присоединяется ИЗ пункта и просачивается оператор Where
- Это делает более сложные ЛЕВЫЕ, ПРАВИЛЬНЫЕ, ПОЛНЫЕ Внешние объединения намного легче
- Справка MSSQL является все базирующейся вокруг того синтаксиса, поэтому намного легче получить справку на Ваших проблемных запросах
В то время как нет никакого различия технически, необходимо быть дополнительны осторожный относительно выполнения соединений с помощью первого метода. Если Вы понимаете его превратно случайно, Вы могли бы закончить тем, что делали декартово соединение между своим a и b таблицами (очень длинное, память и CPU интенсивный запрос - это будет соответствовать каждой одной строке в со всеми строками в b. Плохо, если a и b являются большими таблицами для начала). Используя явное ВНУТРЕННЕЕ ОБЪЕДИНЕНИЕ и более безопасно и легче читать.
Никакое различие. Я нахожу первый формат более читаемым и использую второй формат только при выполнении других типов соединений (ВНЕШНИЙ, ОСТАВЛЕННЫЙ ВНУТРЕННИЙ, и т.д.).
Нет никакого различия к механизму запроса SQL.
Для удобочитаемости последнего намного легче считать, если Вы используете разрывы строки и добавление отступа.
Для ВНУТРЕННИХ ОБЪЕДИНЕНИЙ не имеет значения при помещении "фильтров" и "соединений" в НА или оператор Where оптимизатор запросов должен решить, что сделать сначала так или иначе (это может, принял решение сделать фильтр сначала, соединение позже, или наоборот
Для ВНЕШНИХ ОБЪЕДИНЕНИЙ однако, существует различие, и иногда Вы будете хотеть вставить условие НА пункте, иногда в ГДЕ. Помещение условия в операторе Where для ВНЕШНЕГО ОБЪЕДИНЕНИЯ может превратить его во ВНУТРЕННЕЕ ОБЪЕДИНЕНИЕ (из-за того, как АННУЛИРУЕТ работу),
Например, проверьте удобочитаемость между двумя после образцов:
SELECT c.customer_no, o.order_no, a.article_no, r.price
FROM customer c, order o, orderrow r, article a
WHERE o.customer_id = c.customer_id
AND r.order_id = o.order_id
AND a.article_id = r.article_id
AND o.orderdate >= '2003-01-01'
AND o.orderdate < '2004-01-01'
AND c.customer_name LIKE 'A%'
ORDER BY r.price DESC
по сравнению с
SELECT c.customer_no, o.order_no, a.article_no, r.price
FROM customer c
INNER JOIN order o
ON o.customer_id = c.customer_id
AND o.orderdate >= '2003-01-01'
AND o.orderdate < '2004-01-01'
INNER JOIN orderrow r
ON r.order_id = o.order_id
INNER JOIN article a
ON a.article_id = r.article_id
WHERE c.customer_name LIKE 'A%'
ORDER BY r.price DESC
Вторая форма является совместимым синтаксисом SQL92. Это должно означать, что поддерживается всеми нынешними и будущими поставщиками баз данных. Однако истина - то, что первая форма является столь распространяющейся, что она, как также гарантируют, будет вокруг для дольше, чем мы заботимся.
Иначе они - то же во всех отношениях в том, как базы данных рассматривают два.