:brickwall: Надявам се, че темата ще намери почитатели е поне дузина, ако не е така супер тогава само аз ще обирам банки. Та аз изучавам усърдно този странен език с хиляди стандарти и всяка помощ ми е добре дошла, надявам се да си бъдем полезни.
Та имам си аз две таблици които са в релационна връзка:*
Релация м/у В->В1
Трябва ми заявка която да ми измъкне info от колона C i C1 като се спази релационната връзка В->В1, абе тябва да изглежда така:
C | C1 |
------------------------------
213 | fafafafafa |
234 | sdgfsdgdsg |
Мерси предварително.
Проблем помагайте!!!!!!!!!!
Работя с MS SQL SERVER.2000 (NOTEBOOK, PIII 700MH, 128RAM, DB 20Mb, OS WIN2000 SERVER SP4), проблема се състои в това, че "Enterprise Menager" се бави адски много 7-15 минути за съвсем прости действия. Например отварянетъо на базата отнема 5-6 минути. Преди няколко дена беше за 0.5-1 минута. Ся какво му стана немога да се светна. Аиде със здраве и ако някой има идея да ми пише.
Някой може ли да ми даде смислено обяснение защо не работи следната заявка (вече ще ги наричам заядчици от заяждане дрън дрън) та* на темат:
SELECT* *
FROM* *CLIENT
WHERE* NAME LIKE '%СТЕФ%'
като колона "NAEM"* = NVARCHAR
Заявката не ми връща нищо, а има "СТЕФКА" В КОЛОНА "NAME" ? ? ? ? ?
Ако обаче използвам числа или латиница няма проблем, заявката се изпълнява успешно, но в момента в които стане дума за кирила край с резултатите.
От сега да предупредя, че не съм спец и не искам да подвеждам никого.
Наистина мисля, че проблемът е в кодовите таблици.
Най-добре е още когато се създава базата да се указват енкодингите на колоните, в които се очаква да има кирилица.
Ако вече е късно за такъв подход, може да се преправят данните в базата (особено ако не е много голяма и ако към нея ще текат много такива заявки). Нещо като: ALTER TABLE `CLIENT` CHANGE CHARACTER SET cp1251 COLLATE cp1251_bulgarian_ci
Но може да опиташ и друго - в самата заявка да укажеш енкодинга: SELECT * FROM CLIENT
WHERE NAME LIKE _bulgarian '%СТЕФ%' COLLATE cp1251_bulgarian_ci;
@SisLog
Първо - опитай дали вместо '%СТЕФ%', няма да проработи '*СТЕФ*' - споменал си нещо за MS SQL SERVER
Второ - думата NAME е резервирана по ANSI стандарта - опитай с CLIENT.NAME
Понеже и аз съм новообранец в тази област, искам да попитам следното нещо. Как да вмъкна нова колона, чрез SQL заявка, която прави математически операции (като умножение и деление) с преднишните колони. Примерно:
А | B | C
---------------------
1 | 31 | А*B
Какво трябва да представлява заявката, за да създаде C колоната, която прави умножение между A и B.
Извинявам се за елементарния въпрос, но все пак си е въпрос
И аз се извинявам за отговора, обаче:
1. сигурен ли си, че е добра идея да имаш колона, чиято сойност може да се изчисли от останалите? Обикновено не се прави така.
2. ALTER TABLE името на таблицата ADD името на новата колона DATATYPE...
това добавя колоната, после ще трябва само да я попълниш с произведенията: UPDATE таблица SET c=a*b
3. В зависимост от това на какво пишеш (MySQL, Oracle...), потърси "triggers" - това е начин да обвържеш стойността в новата колонка с предишните две.
Към това, което е написала Bibi, мога да ти предложа да потърсиш в Reference на използваната от теб база дали се поддържат полета от даден тип с опция COMPUTED - това е най-лесния начин да имаш изчислено поле - лошото е, че не съм виждал 100% ANSI compliant database
ето едно примерче от MSDN CREATE TABLE t2 (a int, b int, c int, x float,
y AS CASE x
WHEN 0 THEN a
WHEN 1 THEN b
ELSE c
END)
В повечето СУБД, въпросните полета не се пазят като стойност и затова има условности при установяваване на индекс върху тях!
Идеята да има такива полета доколкото знам, е съответствие с бизнес-логиката на продукта, ползващ базата - затова и не са стойности, а функция върху други данни/полета...
М-да - твоя селект върши работа, но когато са милиони записите, малко трудно ще ги калкулира, особено ако те интересува определено подмножество базирано на a*b - затова са и индексите ако/когато са възможни...
Но при милиони записи, това поле колкото и да е малко ще заема чуствителен обем памет на харда.
А ако точно това поле е толкова важно обикновено някое от А,Б може да се представи като функция от Ц и няма да се налага да се пази