Pitane

ot linka deto ti go dawash:

"When capitalized, the term generally refers to either of two database management products from Sybase and Microsoft. Both companies offer client-server DBMS products called SQL Server. "

Towa e malko staro shtoto ot 98-ma g. samo produkta na MS se kazwa "SQL Server", produkta na sybase se kazwa ASE (Adaptive server enterprise). Ne znam dali MS sa otkupili imeto ili sa sadili sybase ili sa gi zaplashili sas sad, no gorkite sybase veche ne mogat da vikat "SQL Server"

Kakto i da e -- tova ne e vajno -- po interesni sa podzaiavkite (subquery-tata)

Ами както вече веднъж бях писал тука те американците с техните идиотщнини в авторското и патентното законодателство в скоро време ще го докарат дотам, че ще пишат:

Здрасти TM, Джон TM. Как TM си TM?
Благодаря TM. Добре TM съм TM а TM ти TM?
Хайде TM да TM изпием TM по TM една TM бира TM
Бива TM


После се чудят и маят що им е в рецесия IT бранша.

salle.online.bg/sig

да примера трябва да се придружи с условие, че втората таблица (при теб person) не участва в релацията в отношение много ;-)) ибах ти изказването - имам предвид, че не е 1 към много (многото е person) или много към много

и съответно при твоят пример те не са еквивалентни заявки - съответно не може да ги сравняваш като скорост (ако им сложиш DISTINCT ще станат лично за мен по-смислени и двете и тогава, ако не те мързи ще е интересно да погледнеш и да кажеш кво ще стане - просто аз съм любопитен, па са ме мързи ;-))))

обаче пък join-а може да се осмисли и като в select-а му сложиш birth_date, т.е. select first_name, last_name, birth_date (такъв резултат със събселекта не можеш да получиш)

(и в двата случая под осмисляне(с birth_date) или по-смислено (с DISTINCT) имам предвид, че в този си вид и двете заявки на мен лично ми се струва, че дават некъкси не съвсем употребими резултати)

да аз за това пояснявам, щото повечето хора си мислят, че SQL Server е едва ли не единсвеният такъв, и както salle казва тея с тези глупави TM-та скоро верно нема да може да си говорят

незнам дали малки големи букви имат значение при TM-тата, ама кво в един учебник като ти пише sql server, те в общият случай нямат предвид на ms ... незнам как се справят с тези работи (или с това дето като продаваш прозорци трябва да плащаш пак на ms .... :-))) а бе имаше неква простотия и с това TM)

Iskam da pomolia za savet otnosno tablicite s relacii pri n-m relationship.
V moia slu4ai imam edna tablica sas statii, edna s produkti i edna s relaciite mezhdu tiah. Vaprosat mi e kak spored vas e nai-udobno da se napravi navigaciata. Standartno si imam po edna forma za vsiaka tablica, no bi bilo po-udobno v formata za statii ditektno da se vavezhdat saotvetni produkti. Prosto ako niakoi e pravil ne6to takova 6te se radvam da spodeli malko opit.

Blagodaria predvaritelno

н:м е винаги свинско. Зависи как потребителите въвеждат данните. Например ако от статията е ясно за какви продукти се отнася, на формата за въвеждане на статии е гот да има търсене на продукти и да даваш възможност в резултата от търсенето да отбелязват (например с checkbox) кои продукти да се закачат за статията. Търсенето трябва да връща само продуктите, които още не са закачени за статията. Хубаво е да можеш да показваш кои продукти за закачени за статията и да модат да ги откачат. Също за дадена статия е хубаво да да има функция "въведи продукт и го закачи за статията". Също бих направил два рипорта (пак ша ма питат на къв език пиша): "Статии без продукти" и "Продукти без статии"

Blagodaria za saveta. Ima dosta da se poraboti. Za sega 6te napravia ne6to maximalno oprosteno, za da ima rabote6ta sistema s linkove mezhdu vsi4ki formi. To si e samo za vatre6no polzvane, istinskite potrebiteli samo 6te 4etat. I bez tova principno samo klienti koito sa si platili triabva da mogat da vavezhdat.