2011-12-09 14 views
5

Chcę wybrać wiersze z tabeli o nazwie Users, gdzie kolumna Logon jest równa "foo" - Jednak chcę również zwrócić "Foo" lub "FOO".Czy w Oracle istnieje sposób na rozróżnianie wielkości liter w kolumnie?

mógłby zrobić coś takiego:

SELECT Id, Name FROM Users WHERE UPPER(Logon) = 'FOO'; 

a następnie przekonwertować mój parametr na wielkie litery. Jednak w naszym kodzie mamy dosłownie setki miejsc, w których musielibyśmy to zaktualizować.

Czy istnieje sposób, aby sam schemat tabeli nie powodował rozróżniania wielkości liter, aby te zapytania działały bez modyfikacji? Dzięki!

UPDATE

I raczej nie zmieni wielkości liter w całej bazy danych lub na poziomie sesji. Zmiana zapytań SQL jest trudna, ponieważ używamy architektury Entity Framework .NET i mamy kwerendy LINQ dla tej tabeli w każdym miejscu. Nie wygląda na to, że EF obsługuje automatyczną konwersję przypadku, chyba że chcesz zmienić także każde zapytanie LINQ.

+0

Sprawdź http://stackoverflow.com/questions/2001165/oracle-11g-case-insensi tive-by-default – a1ex07

+0

Szukam sposobu na kontrolę poziomu tabeli i/lub kolumny, nie chcę teraz zmieniać całej bazy danych. –

Odpowiedz

3

Odpowiadając na moje własne pytanie, ponieważ nie sądziłem, że któraś z proponowanych odpowiedzi naprawdę rozwiązuje problem.

Oracle nie obsługuje koncepcji typu kolumny niewrażliwe na wielkość liter, a wielkość liter może być kontrolowana tylko na poziomie bazy danych lub sesji. Można to obejść na kilka sposobów, na przykład przez uczynienie kolumny wirtualną lub odczytanie widoku, ale każdy z nich również wymagałby podania odpowiedniego operandu (na przykład: WHERE X = UPPER(:p1).A.

Skończyło się na aktualizacji mojej bazy danych (która była listą nazw użytkowników z Active Directory), aby mieć poprawne przypadki, więc nie muszę już porównywać wielkości liter.

0

You mógłby skonfigurować widok na stole ze wszystkimi kolumnami identyczne, z wyjątkiem kolumny dotkniętego które byłyby upshifted - coś jak:

create view v_Users as 
select Id, Name, UPPER(Logon) Logon, ... 
FROM Users 

- wtedy nie globalny wymienić na kodzie źródłowym aby zmienić nazwę tabeli na nazwę widoku - mimo, że tabela nazywa się Użytkownicy, może to być niebezpieczne ...

+2

Musiałby także zmienić wszystkie swoje zapytania, aby przekazać Logon jako wielkie litery, czego właśnie próbuje uniknąć. –

+1

Tak, to jest jeden pomysł, nadal musiałbym napisać ponownie wszystkie selekcje, aby obsłużyć prawy operand na wielką literę. Jeśli mam to zrobić, równie dobrze mogę po prostu zaktualizować wszystkie miejsca, w których szukam użytkowników Logonem - Co myślę o tym, co muszę zrobić :) –

1

Nie sądzę, że można to zrobić tylko dla jednej kolumny. Możesz wypróbować następujące podejście: ustaw wirtualną kolumnę Logon jako UPPER(s_Logon) (utwórz s_Logon, skopiuj wszystkie wartości z istniejącej kolumny Logon, upuść Logon, utwórz ją jako wirtualną). Wierzę, że zadziała dla SELECT s, ale dla insert/update s będziesz musiał uzyskać dostęp do "s_Logon". Mam nadzieję, że ma to sens.

+0

Czy to nie wystarczy, by kolumna była zawsze wielka? ? Nadal musiałbym rzucać prawy operand na wielką literę, gdybym to porównał. –

2

Wolałbym nie zmieniać wielkości liter w całej bazie danych lub podczas sesji poziom:

Czy istnieje sposób, aby uczynić sam schemat tabeli niewrażliwym na wielkość liter, aby te zapytania działały bez modyfikacji

Tak, jest to możliwe, ale z wersji Oracle 12cR2 i nowszych.Można zdefiniować go na wielu poziomach (kolumna tabeli, schematu):

-- default 
CREATE TABLE tab2(i INT PRIMARY KEY, name VARCHAR2(100)); 

INSERT INTO tab2(i, name) VALUES (1, 'John'); 
INSERT INTO tab2(i, name) VALUES (2, 'Joe'); 
INSERT INTO tab2(i, name) VALUES (3, 'Billy'); 

SELECT /*csv*/ * 
FROM tab2 
WHERE name = 'jOHN' ; 
/* 
"I","NAME" 
no rows selected 
*/ 

SELECT /*csv*/ 
     column_id, 
     column_name, 
     collation 
FROM user_tab_columns 
WHERE table_name = 'TAB2' 
ORDER BY column_id; 
/* 
"COLUMN_ID","COLUMN_NAME","COLLATION" 
1,"I","" 
2,"NAME","USING_NLS_COMP" 
*/ 

Kolumna poziomie:

CREATE TABLE tab2(i INT PRIMARY KEY, name VARCHAR2(100) COLLATE BINARY_CI); 

INSERT INTO tab2(i, name) VALUES (1, 'John'); 
INSERT INTO tab2(i, name) VALUES (2, 'Joe'); 
INSERT INTO tab2(i, name) VALUES (3, 'Billy'); 

SELECT /*csv*/ * 
FROM tab2 
WHERE name = 'jOHN' ; 
/* 
"I","NAME" 
1,"John" 
*/ 

-- COLUMN LEVEL 

SELECT /*csv*/ 
     column_id, 
     column_name, 
     collation 
FROM user_tab_columns 
WHERE table_name = 'TAB2' 
ORDER BY column_id; 
/* 
"COLUMN_ID","COLUMN_NAME","COLLATION" 
1,"I","" 
2,"NAME","BINARY_CI" 
*/ 

poziomie tabeli:

CREATE TABLE tab2(i INT PRIMARY KEY, name VARCHAR2(100)) 
DEFAULT COLLATION BINARY_CI; 

Schema-level:

CREATE USER myuser IDENTIFIED BY myuser 
DEFAULT TABLESPACE users 
DEFAULT COLLATION BINARY_CI; 
+1

Schludny element - o tym nie słyszałem. Więcej tutaj: https://oracle-base.com/articles/12c/column-level-collation-and-case-insensitive-database-12cr2 –

Powiązane problemy