Разве все это не предполагает, что базовый класс является модернизированным классом?
class A:
def __init__(self):
print("A.__init__()")
class B(A):
def __init__(self):
print("B.__init__()")
super(B, self).__init__()
не будет работать в Python 2. class A
, должен быть новый стиль, т.е.: class A(object)
Просто обратите внимание, что вам может быть лучше иметь 3 отдельных SELECTS из соображений оптимизации. Если у вас есть один единственный SELECT, то сгенерированный план должен будет проецировать все столбцы col1, col2, col3, col7, col8 и т. Д., Хотя, в зависимости от значения времени выполнения @var, необходимы только некоторые. Это может привести к планам, которые выполняют ненужный поиск по кластеризованному индексу, поскольку некластеризованный индекс не покрывает все столбцы, спроецированные с помощью SELECT.
С другой стороны, 3 отдельных SELECTS, каждый, проецирующий только необходимые столбцы, может выиграть от некластеризованных индексов, которые в каждом случае охватывают только ваш прогнозируемый столбец.
Конечно, это зависит от фактической схемы вашей модели данных и точных запросов, но это всего лишь предупреждение, поэтому вы не переносите повелительное мышление процедурного программирования в декларативный мир SQL.
Попробуйте что-нибудь вроде
SELECT
CASE var
WHEN xyz THEN col1
WHEN zyx THEN col2
ELSE col7
END AS col1,
...
Другими словами, используйте условное выражение для выбора значения, а затем переименуйте столбец.
В качестве альтернативы вы можете создать какой-нибудь динамический SQL-хак, чтобы совместно использовать хвост запроса; Я уже делал это с iBatis раньше.
Вы ищете оператор CASE
http://msdn.microsoft.com/en-us/library /ms181765.aspx
Пример скопирован из MSDN:
USE AdventureWorks;
GO
SELECT ProductNumber, Category =
CASE ProductLine
WHEN 'R' THEN 'Road'
WHEN 'M' THEN 'Mountain'
WHEN 'T' THEN 'Touring'
WHEN 'S' THEN 'Other sale items'
ELSE 'Not for sale'
END,
Name
FROM Production.Product
ORDER BY ProductNumber;
GO
CASE - это ответ, но вам потребуется отдельный оператор case для каждого столбца, который вы хотите вернуть. Пока предложение WHERE остается тем же самым, не будет особой пользы от разделения его на несколько запросов.
Пример:
SELECT
CASE @var
WHEN 'xyz' THEN col1
WHEN 'zyx' THEN col2
ELSE col7
END,
CASE @var
WHEN 'xyz' THEN col2
WHEN 'zyx' THEN col3
ELSE col8
END
FROM Table
...
The most obvious solutions are already listed. Depending on where the query is sat (i.e. in application code) you can't always use IF statements and the inline CASE statements can get painful where lots of columns become conditional. Assuming Col1 + Col3 + Col7 are the same type, and likewise Col2, Col4 + Col8 you can do this:
SELECT Col1, Col2 FROM tbl WHERE @Var LIKE 'xyz'
UNION ALL
SELECT Col3, Col4 FROM tbl WHERE @Var LIKE 'zyx'
UNION ALL
SELECT Col7, Col8 FROM tbl WHERE @Var NOT LIKE 'xyz' AND @Var NOT LIKE 'zyx'
As this is a single command there are several performance benefits with regard to plan caching. Also the Query Optimiser will quickly eliminate those statements where @Var doesn't match the appropriate value without touching the storage engine.