959

සරල බව සඳහා, අදාළ සියලු ක්ෂේත්‍ර යැයි උපකල්පනය කරන්න NOT NULL.

ඔබට කළ හැකිය:

SELECT
    table1.this, table2.that, table2.somethingelse
FROM
    table1, table2
WHERE
    table1.foreignkey = table2.primarykey
    AND (some other conditions)

නැතහොත්:

SELECT
    table1.this, table2.that, table2.somethingelse
FROM
    table1 INNER JOIN table2
    ON table1.foreignkey = table2.primarykey
WHERE
    (some other conditions)

මේ දෙදෙනා එකම ආකාරයකින් ක්‍රියා MySQLකරනවාද?

— JCCyC
source

1

Ar මාකෝ: මෙන්න එයයි

— ඇලෙක්සැන්ඩර් මලකොව්

1

SQL වමේ

— සිරෝ සැන්ටිලි 郝海东冠状病六四事件法轮功

19

මා නිවැරදිව තේරුම් ගෙන ඇත්නම්, පළමු ප්‍රභේදය ANSI SQL-89 ව්‍යංග සින්ටැක්ස් වන අතර දෙවන ප්‍රභේදය ANSI SQL-92 පැහැදිලි සම්බන්ධක සින්ටැක්ස් වේ. දෙකම SQL ක්‍රියාවට නැංවීමේදී එකම ප්‍රති result ලයක් ලබා දෙන අතර දෙකම හොඳින් සිදුකරන ලද SQL ක්‍රියාත්මක කිරීමේදී එකම විමසුම් සැලැස්මක් ඇති කරයි. මම පුද්ගලිකව SQL-89 සින්ටැක්ස් වලට කැමතියි නමුත් බොහෝ අය SQL-92 සින්ටැක්ස් වලට කැමතියි.

— මිකෝ රන්ටලයිනන්

11

Og හොගන් මම විවිධ සින්ටැක්ස් සඳහා නිල නම් පෙන්වා දුන්නා. කිසිම පිළිතුරක් සම්පූර්ණ නම් පැහැදිලිව දක්වා නැති නිසා ඒවා අදහස් ලෙස එක් කිරීමට මම තීරණය කළෙමි. කෙසේ වෙතත්, මගේ අදහස සත්‍ය ප්‍රශ්නයට පිළිතුරු නොදුන් නිසා මම එය අදහස් දැක්වීමක් ලෙස නොව පිළිතුරක් ලෙස එකතු කළෙමි. (මහා පිළිතුරු වැනි හිමිකම් පෑම ඡන්දය "ඇතුල් එක්වන ANSI කාරක රීති වේ" සහ "ගම්ය ANSI කාරක රීති එක්වන පැරණි" syntaxes දෙකම වෙනස් ANSI syntaxes නිසා සියලු කිසිවක් කියන.)

— Mikko Rantalainen

718

INNER JOIN යනු ඔබ භාවිතා කළ යුතු ANSI සින්ටැක්ස් ය.

එය සාමාන්‍යයෙන් වඩා කියවිය හැකි යැයි සැලකේ, විශේෂයෙන් ඔබ බොහෝ වගු වලට සම්බන්ධ වූ විට.

OUTER JOINඅවශ්‍යතාවයක් ඇති විටෙක එය පහසුවෙන් ප්‍රතිස්ථාපනය කළ හැකිය .

මෙම WHEREකාරක රීති ආදර්ශ කරගත් තවත් සම්බන්ධීය.

වගු දෙකක JOINසංස්කරණයේ ප්‍රති result ලයක් ලෙස වගු වල කාටිසියානු නිෂ්පාදනයක් වන අතර එය පෙරනයක් යොදන අතර එමඟින් ගැලපෙන තීරු ගැලපෙන පේළි පමණක් තෝරා ගනී.

WHEREසින්ටැක්ස් සමඟ මෙය දැකීම පහසුය .

ඔබේ උදාහරණය සඳහා, MySQL හි (සහ සාමාන්‍යයෙන් SQL වලින්) මෙම විමසුම් දෙක සමාන පද වේ.

MySQL හි STRAIGHT_JOINවගන්තියක් ද ඇති බව සලකන්න .

මෙම වගන්තිය භාවිතා කරමින්, ඔබට JOINඅනුපිළිවෙල පාලනය කළ හැකිය : පිටත පුඩුවේ කුමන වගුව පරිලෝකනය කර ඇත්ද සහ අභ්‍යන්තර පුඩුවේ ඇති වගුව.

WHEREසින්ටැක්ස් භාවිතයෙන් ඔබට මෙය MySQL හි පාලනය කළ නොහැක .

— ක්වාස්නෝයි
source

12

ස්තූතියි, ක්වාස්නෝයි. ඔබේ පිළිතුරුවල විවිධ තොරතුරු ඔබ සතුව ඇත; "ඔව්, එම විමසුම් සමාන වේ, නමුත් ඔබ කියවිය හැකි සහ වෙනස් කිරීමට පහසු නිසා අභ්‍යන්තර බැඳීම භාවිතා කළ යුතුය" යනුවෙන් පැවසීම සාධාරණද?

— allyourcode

8

@allyourcode: සඳහා Oracle, SQL Server, MySQLහා PostgreSQL- ඔව්. වෙනත් පද්ධති සඳහා, බොහෝ විට, නමුත් ඔබ වඩා හොඳින් පරීක්ෂා කරන්න.

— ක්වාස්නෝයි

13

FWIW, WHEREවගන්තියේ එක්වීමේ කොන්දේසි සහිත කොමාව භාවිතා කිරීම ද ANSI ප්‍රමිතියේ ඇත.

— බිල් කාර්වින්

1

@Bill Karwin: JOINයතුරුපදය අතීතයේ මෑතක් වන තුරුම හිමිකාර ප්‍රමිතිවල කොටසක් නොවීය. එය කරා ප්රවිෂ්ටව Oracleඅනුවාදය පමණක් 9සහ බවට PostgreSQLඅනුවාදය 7.2(දෙකම නිකුත් 2001). මෙම මූල පදය පෙනුම කොටසක් විය ANSIසම්මත සම්මත අතර, මෙම ඉඟි පද සාමාන්යයෙන් සමග සංෙයෝජිත ෙකෙර් ඒකයි ANSIසඳහා පර්යාය පදයක් ලෙස අග ආධාරක කොමා තිබියදීත්, CROSS JOINමෙන්ම.

— ක්වාස්නෝයි

9

එසේ වුවද, ANSI SQL-89 නිශ්චිතව දක්වා ඇති බැඳීම් කොමා සහ කොන්දේසි සමඟ WHEREවගන්තියක සිදු කළ යුතුය (කොන්දේසි නොමැතිව, එක්වීම ඔබ පැවසූ පරිදි හරස් බැඳීමකට සමාන වේ). ANSI SQL-92 JOINයතුරුපදය සහ අදාළ වාක්‍ය ඛණ්ඩය එක් කළ නමුත් කොමා විලාසිතාවේ සින්ටැක්ස් පසුගාමී අනුකූලතාව සඳහා තවමත් සහය දක්වයි.

— බිල් කාර්වින්

188

තවත් සමහරු පෙන්වා දී ඇත්තේ එය INNER JOINමිනිස් කියවීමේ හැකියාව සඳහා උපකාරී වන අතර එය ප්‍රමුඛතාවයකි, මම එකඟ වෙමි. සම්බන්ධ වීමේ වාක්‍ය ඛණ්ඩය වඩාත් කියවිය හැක්කේ මන්දැයි
පැහැදිලි කිරීමට මම උත්සාහ කරමි .

මූලික SELECTවිමසුමක් මෙයයි:

SELECT stuff
FROM tables
WHERE conditions

මෙම SELECTවගන්තිය අපට පවසනවා දේ අපි නැවත ලබා කරන්නේ, මෙම FROMවගන්තිය අපට පවසනවා එහිදී අපි එය වෙලානේ ඉන්නේ, සහ WHEREවගන්තිය අපට පවසනවා වන අය අපි යන්නේ.

JOIN වගු පිළිබඳ ප්‍රකාශයකි, ඒවා එකට බැඳී ඇති ආකාරය (සංකල්පමය වශයෙන්, ඇත්ත වශයෙන්ම, තනි වගුවකට).

වගු පාලනය කරන ඕනෑම විමසුම් මූලද්‍රව්‍යයන් - අප විසින් දේවල් ලබා ගන්නේ කොතැනින්ද - අර්ථයෙන් FROMවගන්තියට අයත් වේ (ඇත්ත වශයෙන්ම, JOINමූලද්‍රව්‍ය යන්නේ එතැනිනි). එක්වන මූලද්‍රව්‍යයන් WHEREවගන්තියට ඇතුළත් කිරීමෙන් කුමන සහ කොතැනින්ද යන්න සම්බන්ධ වේ , එම නිසා JOINසින්ටැක්ස් වඩාත් කැමති වේ.

— කාල් මැනස්ටර්
source

8

අභ්‍යන්තර බැඳීම කාල්ට කැමති වීමට හේතුව පැහැදිලි කිරීමට ස්තූතියි. මම හිතන්නේ ඔබේ පිළිතුර අනෙක් අය තුළ ගම්‍ය වේ, නමුත් පැහැදිළිවම වඩා හොඳය (ඔව්, මම පයිතන් රසිකයෙක්).

— allyourcode

2

ON සහ WHERE හි අර්ථ නිරූපණයන්හි අර්ථය වන්නේ අවසාන පිටත සම්බන්ධ වීමෙන් පසුව සම්බන්ධ වීම සඳහා ඔබ භාවිතා කරන දෙය වැදගත් නොවේ . ඔබ එක්වන කොටසක් ලෙස පිළිබඳ චරිත ලක්ෂණ වුවත්, එය ද ඉතා කාටිසීය නිෂ්පාදන පසු පෙරහන්. ON සහ WHERE යන දෙකම කාටිසියානු නිෂ්පාදනයක් පෙරහන් කරයි. නමුත් අන්තිම පිටත සම්බන්ධ වීමට පෙර ON හෝ WHERE සමඟ උප තේරීමක් භාවිතා කළ යුතුය . (... නැත තීරුව යුගල හා "" ඕනෑම වගු දෙකක් ඕනෑම කොන්දේසියක් එක්වූ කළ හැකි ඒ අර්ථ නිරූපණය කිරීමට පමණක් ක්රමයක් විශේෂයෙන් තීරු සමානාත්මතාවය පිළිබඳ එක්වෙයි තියෙන්නේ වේ එක්වේ)

— philipxy

1

INNER JOIN හි එකම බලපෑමට ඔබ WHERE භාවිතා කරන විටදී පවා, ඔබ ඔබේ වගු දෙක විමසුමේ FROM කොටසේ සඳහන් කිරීමට යන්නේ ය. එබැවින් මූලික වශයෙන් ඔබ තවමත් ඔබේ දත්ත FROM වගන්තියෙන් ලබා ගන්නේ කොහෙන්ද යන්න ඇඟවුම් කරයි, එබැවින් ඔබට එය අනිවාර්යයෙන්ම "කොහෙන්ද සහ කොතැනින්ද යන්න

— අවුල් කරයි

RsArsenKhachaturyan පා key යක් තුළ යතුරු පදයක් හෝ හඳුනාගැනීමක් භාවිතා කළ පමණින් එය කේතයක් නොවන අතර කේත ආකෘතිය අවශ්‍ය වේ. එය ඕනෑම ආකාරයකින් යා හැකි ආකෘතිකරණ තේරීමක් වන අතර මෙහි සංස්කරණය කිරීම සාධාරණ නම් සෑම පෝස්ටයක්ම අනෙක් ආකෘතියට නිරන්තරයෙන් සංස්කරණය කිරීම යුක්ති සහගත ය - එනම් එය යුක්ති සහගත නොවේ. (ප්ලස් ඉන්ලයින් එක්-වචන කේත ආකෘතිය කියවීම දුෂ්කර විය හැකිය.) මෙහි ඡේදය කැඩී යාම සඳහා සමාන වේ - ඒවා විශේෂයෙන් පැහැදිලි කර නැත. 'කුමන' එදිරිව 'ඒ හා සමානයි. ක්‍රමලේඛන භාෂාවල නම් කේත ආකෘතියෙන් නොවිය යුතුය. PS ඔබ වැරදීමකින් පේළි කඩනයක් එකතු කළා.

— philipxy

ilphilipxy ඔබ සඳහන් කළ පරිදි "එයින් අදහස් නොකෙරේ ...", නමුත් පැහැදිලිවම එයින් අදහස් කළේ එය කේත මූල පදයෙන් සලකුණු කළ නොහැකි බවයි. ඔව්, එය තෝරා ගැනීමක් වන නමුත් එම කාරණය නොදැන බොහෝ තනතුරු සිදු කරනු ලැබේ. එබැවින් වෙනස්කම් කිරීමට මා ගත් තීරණය කිසිවක් බිඳ දැමීමට නොව එය වඩාත් කියවිය හැකි කිරීමට අදහස් කරයි. වෙනස්කම් සැකසීමෙන් පසු යම් විවේකයක් ඔබ දුටුවා නම්, ඒ ගැන කණගාටුයි, ඔබට පැහැදිලිවම එවැනි වෙනස්කම් ආපසු හැරවිය හැකිය.

— අර්සන් කචතුරියන්

145

ON / WHERE හි කොන්දේසි සහිත ප්‍රකාශ යෙදීම

මෙහිදී මම තාර්කික විමසුම් සැකසුම් පියවර ගැන පැහැදිලි කර ඇත්තෙමි.

යොමුව: ඇතුළත Microsoft® SQL Server T 2005 T-SQL විමසුම්
ප්‍රකාශක: මයික්‍රොසොෆ්ට් ප්‍රෙස්
පබ් දිනය: මාර්තු 07, 2006
මුද්‍රණය ISBN-10: 0-7356-2313-9
මුද්‍රණය ISBN-13: 978-0-7356-2313-2
පිටු: 640

Microsoft® SQL Server ™ 2005 T-SQL විමසුම තුළ

(8)  SELECT (9) DISTINCT (11) TOP <top_specification> <select_list>
(1)  FROM <left_table>
(3)       <join_type> JOIN <right_table>
(2)       ON <join_condition>
(4)  WHERE <where_condition>
(5)  GROUP BY <group_by_list>
(6)  WITH {CUBE | ROLLUP}
(7)  HAVING <having_condition>
(10) ORDER BY <order_by_list>

අනෙකුත් ක්‍රමලේඛන භාෂාවන්ට වඩා වෙනස් SQL හි පළමු කැපී පෙනෙන අංගය වන්නේ කේතය සැකසූ අනුපිළිවෙලයි. බොහෝ ක්‍රමලේඛන භාෂාවල, කේතය එය ලියා ඇති අනුපිළිවෙලට සකසනු ලැබේ. SQL හි, සැකසූ පළමු වගන්තිය FROM වගන්තිය වන අතර, පළමුව පෙනෙන SELECT වගන්තිය අවසන් වරට පාහේ සකසනු ලැබේ.

සෑම පියවරක්ම පහත පියවරට ආදානය ලෙස භාවිතා කරන අථත්‍ය වගුවක් ජනනය කරයි. මෙම අථත්ය වගු ඇමතුම්කරුට ලබා ගත නොහැක (සේවාදායක යෙදුම හෝ බාහිර විමසුම). අවසාන පියවර මගින් ජනනය කරන ලද වගුව පමණක් නැවත අමතන්නා වෙත යවනු ලැබේ. විමසුමක කිසියම් වගන්තියක් නිශ්චිතව දක්වා නොමැති නම්, අනුරූප පියවර සරලව මඟ හරිනු ලැබේ.

තාර්කික විමසුම් සැකසුම් අවධීන් පිළිබඳ කෙටි විස්තරයක්

පියවර පිළිබඳ විස්තරය දැනට එතරම් අර්ථවත් නොවන බව පෙනේ නම් ඕනෑවට වඩා කරදර නොවන්න. මේවා යොමු කිරීමක් ලෙස සපයනු ලැබේ. සිද්ධි උදාහරණයෙන් පසුව එන කොටස් වඩාත් විස්තරාත්මකව පියවර ආවරණය කරයි.

FROM: FROM වගන්තියේ පළමු වගු දෙක අතර කාටිසියානු නිෂ්පාදනයක් (හරස් බැඳීම) සිදු කරන අතර එහි ප්‍රති V ලයක් ලෙස VT1 අතථ්‍ය වගුව ජනනය වේ.
ON: ON පෙරණය VT1 සඳහා යොදනු ලැබේ. <join_condition>සත්‍යය වන පේළි පමණක් VT2 ට ඇතුළත් කර ඇත.
පිටත (එක්වන්න): පිටත සම්බන්ධතාවයක් නිශ්චිතව දක්වා තිබේ නම් (CROSS JOIN හෝ INNER JOIN වලට වෙනස්ව), සංරක්‍ෂිත වගුවේ හෝ ගැලපීමක් සොයා නොගත් වගු වල පේළි VT2 සිට පේළි වලට පිටත පේළි ලෙස එකතු කර ජනනය කරයි VT3. FROM වගන්තියේ වගු දෙකකට වඩා වැඩි ගණනක් දිස්වන්නේ නම්, සියලු වගු සැකසෙන තෙක් අවසාන සම්බන්ධතාවයේ ප්‍රති result ලය සහ FROM වගන්තියේ ඊළඟ වගුව අතර පියවර 1 සිට 3 දක්වා නැවත නැවතත් යොදනු ලැබේ.
WHERE: WHTE පෙරණය VT3 සඳහා යොදනු ලැබේ. <where_condition>සත්‍යය වන පේළි පමණක් VT4 ට ඇතුළත් කර ඇත.
GROUP BY: GROUP BY වගන්තියේ දක්වා ඇති තීරු ලැයිස්තුව මත පදනම්ව VT4 හි පේළි කණ්ඩායම් වශයෙන් සකස් කර ඇත. VT5 ජනනය වේ.
කියුබ් | ROLLUP: VT5 සිට පේළි වලට සුපිරි කණ්ඩායම් (කණ්ඩායම් කණ්ඩායම්) එකතු කර VT6 ජනනය කරයි.
HAVING: HAVING පෙරණය VT6 සඳහා යොදනු ලැබේ. <having_condition>VT7 වෙත ඇතුළත් කර ඇත්තේ සත්‍ය වන කණ්ඩායම් පමණි .
තෝරන්න: VT8 ජනනය කරමින් SELECT ලැයිස්තුව සකසනු ලැබේ.
DISTINCT: VT8 වෙතින් අනුපිටපත් පේළි ඉවත් කරනු ලැබේ. VT9 ජනනය වේ.
නියෝගය: VT9 හි පේළි ORDER BY වගන්තියේ දක්වා ඇති තීරු ලැයිස්තුවට අනුව වර්ග කර ඇත. කර්සරයක් ජනනය වේ (VC10).
ඉහළට: VC10 ආරම්භයේ සිට නිශ්චිත අංකය හෝ පේළි ප්‍රතිශතය තෝරා ඇත. VT11 වගුව ජනනය කර නැවත අමතන්නා වෙත යවනු ලැබේ.

එබැවින්, (INNER JOIN) ON WHERE වගන්තිය යෙදීමට පෙර දත්ත පෙරහන් කරනු ඇත (VT හි දත්ත ගණන මෙහිම අඩු වේ). පසුකාලීන බැඳීම් කොන්දේසි පෙරහන් කළ දත්ත සමඟ ක්‍රියාත්මක වන අතර එය කාර්ය සාධනය වැඩි දියුණු කරයි. ඊට පසු WHERE කොන්දේසිය පමණක් පෙරහන් කොන්දේසි අදාළ වේ.

(ON / WHERE හි කොන්දේසි සහිත ප්‍රකාශයන් යෙදීමෙන් අවස්ථා කිහිපයකදී විශාල වෙනසක් සිදු නොවේ. මෙය රඳා පවතින්නේ ඔබ එකතු වී ඇති වගු ගණන සහ එක් එක් සම්බන්ධක වගුවල ඇති පේළි ගණන මතය)

— රෆිදීන්
source

10

"එබැවින්, (INNER JOIN) ON මඟින් WHERE වගන්තිය යෙදීමට පෙර දත්ත පෙරහන් කරනු ඇත (VT හි දත්ත ගණන මෙහිම අඩු වනු ඇත)." අවශ්‍ය නොවේ. ලිපිය සැකසීමේ තාර්කික අනුපිළිවෙල ගැන ය. කිසියම් ක්‍රියාවට නැංවීම තවත් දෙයකට පෙර එක් දෙයක් කරනු ඇතැයි ඔබ කියන විට, ඔබ කතා කරන්නේ ක්‍රියාවට නංවන ලද අනුපිළිවෙල ගැන ය. ක්‍රියාත්මක කිරීම තාර්කික අනුපිළිවෙල අනුගමනය කළාක් මෙන් ප්‍රති the ලය සමාන වන තාක් කල්, ඔවුන් කැමති ඕනෑම ප්‍රශස්තිකරණයක් ක්‍රියාත්මක කිරීමට අවසර දෙනු ලැබේ. ජෝ සෙල්කෝ මේ ගැන යූස්නෙට් හි බොහෝ දේ ලියා ඇත.

— මයික් ෂෙරිල් 'කැට් රෙකෝල්'

frafidheen "(INNER JOIN) ON මඟින් දත්ත පෙරහන් කරනු ඇත ... WHERE වගන්තිය යෙදීමට පෙර ... එය කාර්ය සාධනය වැඩි කරයි." හොඳ කරුණක්. “ඊට පසු WHERE කොන්දේසිය පමණක් පෙරහන් කොන්දේසි අදාළ වේ” HAVING වගන්තිය ගැන කුමක් කිව හැකිද?

— ජේම්ස්

@ ජේම්ස් රෆිදීන් විසින් කරන ප්‍රකාශය වැරදිය. අත්පොතේ 'බැඳීම් ප්‍රශස්තිකරණය' බලන්න. එසේම මෙම පිටුවේ මගේ අනෙක් අදහස්. (සහ මයික් ෂෙරිල් කැට් රෙකෝල්ගේ.) එවැනි “තාර්කික” විස්තරයන් විස්තර කරන්නේ ප්‍රති result ල වටිනාකම මිස එය සැබවින්ම ගණනය කරන්නේ කෙසේද යන්න නොවේ. එවැනි ක්‍රියාත්මක කිරීමේ හැසිරීම වෙනස් නොවන බවට සහතික නොවේ.

— philipxy

67

ව්‍යංගයෙන් එක්වන ANSI සින්ටැක්ස් පැරණි, අඩු පැහැදිලිව පෙනෙන අතර නිර්දේශ නොකරයි.

ඊට අමතරව, සම්බන්ධතා වීජ ගණිතය මඟින් WHEREවගන්තියේ සහ අනාවැකි එකිනෙකට හුවමාරු කර ගැනීමට ඉඩ සලසයි INNER JOIN, එබැවින් වගන්ති INNER JOINසමඟ විමසීම් පවා WHEREඅනාවැකි ප්‍රශස්තකරණය මඟින් නැවත සකස් කළ හැකිය.

විමසීම් හැකි තරම් කියවිය හැකි ආකාරයෙන් ලිවීමට මම නිර්දේශ කරමි.

සමහර විට මෙයට INNER JOINසාපේක්ෂව “අසම්පූර්ණ” කිරීම සහ WHEREපෙරීමේ නිර්ණායක ලැයිස්තුව වඩාත් පහසුවෙන් නඩත්තු කළ හැකි වන පරිදි සරල කිරීමට සමහර නිර්ණායක ඇතුළත් කිරීම ඇතුළත් වේ .

උදාහරණයක් ලෙස, ඒ වෙනුවට:

SELECT *
FROM Customers c
INNER JOIN CustomerAccounts ca
    ON ca.CustomerID = c.CustomerID
    AND c.State = 'NY'
INNER JOIN Accounts a
    ON ca.AccountID = a.AccountID
    AND a.Status = 1

ලියන්න:

SELECT *
FROM Customers c
INNER JOIN CustomerAccounts ca
    ON ca.CustomerID = c.CustomerID
INNER JOIN Accounts a
    ON ca.AccountID = a.AccountID
WHERE c.State = 'NY'
    AND a.Status = 1

නමුත් එය රඳා පවතී.

— කේඩ් රූක්ස්
source

17

ඔබේ පළමු ස්නිපටය අනිවාර්යයෙන්ම මගේ මොළයට රිදවයි. කවුරුහරි ඇත්තටම එසේ කරනවාද? එය කරන කෙනෙකු මට හමු වුවහොත්, මම ඔහුට හිසට පහර දීම සුදුසු ද?

— allyourcode

3

එය වඩාත් අර්ථවත් වන නිර්ණායක මම සොයා ගතිමි. මම තාවකාලිකව ස්ථාවර ස්නැප්ෂොට් බැලීමේ වගුවකට සම්බන්ධ වන්නේ නම් (සහ වලංගු දිනයක් තෝරා ගැනීම බලාත්මක කරන දර්ශනයක් හෝ යූඩීඑෆ් මා සතුව නොමැත), මම සම්බන්ධ වීමට බලපැවැත්වෙන දිනය ඇතුළත් කරමි, නමුත් එය අඩු බැවින් අහම්බෙන් ඉවත් වීමට ඉඩ ඇත.

— කේඩ් රූක්ස්

14

@allyourcode: INNER JOINs හි මෙම ආකාරයේ සම්බන්ධ වීමේ වාක්‍ය ඛණ්ඩය දැකීම දුර්ලභ වුවද, RIGHT JOINs සහ LEFT JOINS සඳහා එය සාමාන්‍ය දෙයකි - සම්බන්ධ වීමේ අනාවැකියෙහි වැඩි විස්තරයක් සඳහන් කිරීමෙන් අනුකාරකයක අවශ්‍යතාවය ඉවත් වන අතර ඔබේ පිටත බැඳීම් නොදැනුවත්ව හැරවීම වළක්වයි. INNER JOINs වලට. (INNER JOINs සඳහා මම සැමවිටම පාහේ c.State = 'NY' යන්න WHERE වගන්තියට ඇතුළත් කරන බව එකඟ වුවද)

— ඩේව් මාක්ල්

1

@allyourcode මම අනිවාර්යයෙන්ම ඒක කරනවා! මම කේඩ් සමඟ එකඟ වෙමි .. එසේ නොකිරීමට යහපත් හේතුවක්

— ආත්

31

ව්‍යාජ විමසීම් (ඔබේ පළමු විමසුම ලෙස හැඳින්වෙන්නේ එයයි) වඩාත් ව්‍යාකූල, කියවීමට අපහසු සහ ඔබේ විමසුමට තවත් වගු එකතු කිරීම ආරම්භ කිරීමට අවශ්‍ය වූ විට නඩත්තු කිරීමට අපහසු වේ. විවිධ වගු හතරක් හෝ පහක් මත එකම විමසුමක් හා එක්වීමක් ගැන සිතන්න ... එය බියකරු සිහිනයකි.

පැහැදිලි සම්බන්ධතාවයක් භාවිතා කිරීම (ඔබේ දෙවන උදාහරණය) වඩා කියවිය හැකි සහ නඩත්තු කිරීමට පහසුය.

— matt b
source

49

මට ඊට වඩා එකඟ විය නොහැක. JOIN සින්ටැක්ස් අතිශයින්ම නරක සහ සංවිධානය කිරීමට අපහසුය. WHERE වගන්තිය හා සම්බන්ධ වන වගු 5, 10, වගු 15 ක් සමඟ සම්බන්ධ වන මට ඕනෑ තරම් ප්‍රශ්න තිබේ. ඒවා හොඳින් කියවිය හැකිය. JOIN සින්ටැක්ස් භාවිතයෙන් එවැනි විමසුමක් නැවත ලිවීමෙන් අවුල් ජාලාවක් ඇති වේ. එයින් පෙන්වන්නේ මෙම ප්‍රශ්නයට නිවැරදි පිළිතුරක් නොමැති බවත් එය ඔබට වඩාත් පහසු දේ මත රඳා පවතින බවත්ය.

— නෝවා යෙටර්

33

නෝවා, මම හිතන්නේ ඔබ මෙහි සුළුතරයක් විය හැකියි.

— matt b

2

මට මැට් සහ නෝවාට +1 ලැබෙනවා. මම විවිධත්වයට කැමතියි :). නෝවා පැමිණෙන්නේ කොහෙන්දැයි මට පෙනේ; අභ්‍යන්තර බැඳීම භාෂාවට අලුත් දෙයක් එකතු නොකරන අතර අනිවාර්යයෙන්ම වඩාත් වාචික වේ. අනෙක් අතට, එය ඔබගේ 'කොහේද' තත්වය වඩා කෙටි කළ හැකිය, එයින් අදහස් කරන්නේ කියවීමට පහසු බවය.

— allyourcode

5

ඕනෑම බුද්ධිමත් ඩීබීඑම්එස් විසින් විමසුම් දෙක එකම ක්‍රියාත්මක කිරීමේ සැලැස්මට පරිවර්තනය කරනු ඇතැයි මම සිතමි; කෙසේ වෙතත් යථාර්ථයේ දී සෑම ඩීබීඑම්එස් එකක්ම වෙනස් වන අතර නිසැකවම දැන ගැනීමට ඇති එකම ක්‍රමය වන්නේ ක්‍රියාත්මක කිරීමේ සැලැස්ම සැබවින්ම පරීක්ෂා කිරීමයි (එනම් ඔබට එය ඔබම පරීක්ෂා කර බැලිය යුතුය).

— matt b

තවත් පිළිතුරකින් (SQL ක්‍රියාත්මක කිරීමේ සවිස්තරාත්මක අනුපිළිවෙල සහිත) @rafidheen යෝජනා කළ පරිදි එය සත්‍යයක්ද, එක් වරකට JOINs පෙරහන් කර ඇති අතර, සම්පූර්ණ කාටේෂියානු වගු 3 ක් හෝ වැඩි ගණනක් සමඟ සසඳන විට එක්වීමේ ක්‍රියාකාරිත්වයේ ප්‍රමාණය අඩු කරයි. පෙරහන ප්‍රතික්‍රියාකාරීව යොදන ස්ථානය කුමක්ද? එසේ නම්, JOIN මඟින් කාර්ය සාධනය වැඩි දියුණු කිරීම (වම් / දකුණ සම්බන්ධ වීමේ වාසි මෙන්ම වෙනත් පිළිතුරක් පෙන්වා දී ඇති පරිදි) යෝජනා කරයි.

— ජේම්ස්

26

පැරණි සින්ටැක්ස් භාවිතා කිරීම දෝෂයකට වඩා වැඩි බව මම පෙන්වා දෙමි. ON වගන්තියක් නොමැතිව ඔබ අභ්‍යන්තර සම්බන්ධතා භාවිතා කරන්නේ නම්, ඔබට සින්ටැක්ස් දෝෂයක් ලැබෙනු ඇත. ඔබ පැරණි වාක්‍ය ඛණ්ඩය භාවිතා කර, එහි ඇති වගන්තියේ එක් බැඳීමේ කොන්දේසියක් අමතක කළහොත්, ඔබට හරස් සම්බන්ධතාවයක් ලැබෙනු ඇත. සංවර්ධකයින් බොහෝ විට මෙය නිවැරදි කර ඇත්තේ විශේෂිත යතුරු පදයක් එකතු කිරීමෙනි (සම්බන්ධතාවය නිවැරදි කිරීමට වඩා, එම සම්බන්ධතාවය බිඳී ඇති බව ඔවුන් තවමත් නොදන්නා හෙයින්) ගැටළුව සුව කරන බවක් පෙනෙන්නට තිබුණත් විමසුම සැලකිය යුතු ලෙස මන්දගාමී වනු ඇත.

නඩත්තු කිරීම සඳහා ඔබට පැරණි වාක්‍ය ඛණ්ඩයට හරස් සම්බන්ධයක් තිබේ නම්, ඔබ එකක් ලබා ගැනීමට අදහස් කළේ නම් (හරස් සම්බන්ධතා අවශ්‍ය වන අවස්ථා තිබේ) හෝ එය නිවැරදි කළ යුතු හදිසි අනතුරක් දැයි නඩත්තුකරු දැන ගන්නේ කෙසේද?

ඔබ වම් සම්බන්ධතා භාවිතා කරන්නේ නම් ව්‍යංග වාක්‍ය ඛණ්ඩය නරක වන්නේ මන්දැයි බැලීමට මම ඔබට මෙම ප්‍රශ්නයට යොමු කරමි. සයිබේස් * = එකම අභ්‍යන්තර වගුව සඳහා විවිධ පිටත වගු 2 ක් සහිත ඇන්සි ස්ටෑන්ඩර්ඩ් වෙත

ප්ලස් (මෙහි පුද්ගලික රැන්ට්), පැහැදිළි බැඳීම් භාවිතා කරන ප්‍රමිතිය අවුරුදු 20 ට වඩා පැරණි ය, එයින් අදහස් කරන්නේ ව්‍යාජ බැඳීම් සින්ටැක්ස් එම අවුරුදු 20 සඳහා යල් පැන ගිය එකක් බවයි. අවුරුදු 20 ක් යල් පැන ගිය සින්ටැක්ස් භාවිතයෙන් ඔබ යෙදුම් කේතය ලියනවාද? දත්ත සමුදා කේතය ලිවීමට ඔබට අවශ්‍ය ඇයි?

— HLGEM
source

3

LHLGEM: පැහැදිලිව සම්බන්ධ වීම වඩා හොඳ බව මම සම්පුර්ණයෙන්ම එකඟ වන අතර, ඔබට පැරණි වාක්‍ය ඛණ්ඩය භාවිතා කිරීමට අවශ්‍ය වූ අවස්ථා තිබේ. සැබෑ ලෝක උදාහරණයක්: ඇන්සි ජොයින් ඔරකල් වෙත පිවිසියේ 2001 දී නිකුත් කරන ලද 9i අනුවාදයෙන් පමණක් වන අතර වසරකට පෙර (ප්‍රමිතිය ප්‍රකාශයට පත් වූ මොහොතේ සිට වසර 16 ක් දක්වා) මට 8i ස්ථාපන පොකුරක් සඳහා සහාය වීමට සිදුවිය. විවේචනාත්මක යාවත්කාලීන කිරීම් නිකුත් කිරීමට. මට යාවත්කාලීනයන් දෙකක් පවත්වා ගැනීමට අවශ්‍ය නොවීය, එබැවින් අපි 8i ඇතුළු සියලුම දත්ත සමුදායන්ට එරෙහිව යාවත්කාලීනයන් සංවර්ධනය කර පරීක්ෂා කළෙමු, එයින් අදහස් කළේ අපට ANSI JOINs භාවිතා කළ නොහැකි බවයි.

— ක්වාස්නෝයි

INNER JOIN රහිත සින්ටැක්ස් වඩාත් දෝෂ සහිත බව ඔබ පෙන්වා දෙන විට +1 සිත්ගන්නා කරුණකි. ඔබේ අවසාන වාක්‍යය ගැන මම ව්‍යාකූල වී සිටිමි ... "පැහැදිලි බැඳීම් භාවිතා කරන ප්‍රමිතිය අවුරුදු 17 කි." එහෙනම් ඔබ යෝජනා කරන්නේ INNER JOIN keyword භාවිතා කිරීමටද නැද්ද?

— මාකෝ ඩෙමියෝ

1

Ar මාකෝ ඩෙමෙයෝ, ඔව් සෑම විටම INNER JOIN හෝ JOIN භාවිතා කරන්න (මේ දෙකම එක හා සමානයි) හෝ LEFT JOIN හෝ RIGHT JOIN හෝ CROSS JOIN භාවිතා කරන්න.

— HLGEM

2

"ඔබට අවුරුදු 20 ක් පැරණි දත්ත සමුදා කේතයක් ලිවීමට අවශ්‍ය ඇයි?" - SQL ව්‍යුත්පන්න වගු සඳහා සහය දැක්වීමට පටන් ගත් දා සිට 'යල් පැන ගිය' ඔබ SQL ලියන බව මම දනිමි HAVING. NATURAL JOINඑය INNER JOIN'යල් පැන ගිය' එකක් බවට මා තර්ක කළත් ඔබ භාවිතා නොකරන බව මම දනිමි . ඔව්, ඔබට ඔබේ හේතු තිබේ (ඒවා නැවත මෙහි සඳහන් කිරීමට අවශ්‍ය නැත!): මගේ අදහස නම්, පැරණි වාක්‍ය ඛණ්ඩය භාවිතා කිරීමට කැමති අයට ඔවුන්ගේ හේතු ද ඇති අතර, වාක්‍ය ඛණ්ඩයේ සාපේක්ෂ වයස කිසියම් අදාළත්වයක් තිබේ නම් එය අල්ප ය.

— onedaywhen

1

තවමත් ප්‍රමිතියේ ඇත්තේ කොතැනද (එය නොමැති තැන මට පෙන්වන්න). ඉතින්, යල් පැන ගිය කිසිවක් පෙනෙන්නට නැත. එසේම, මට දර්ශන, පොදුවේ DBMSs ඈත් කර තබා ගත යුතුය නිර්මාණකරුවෙකු "වෙනුවට සවි වඩා එක්වන" දුර ඈතින්.

— ජෝගන් ඒ. අර්හාර්ඩ්

12

ඔවුන්ට වෙනස් මිනිස් කියවිය හැකි අර්ථයක් ඇත.

කෙසේ වෙතත්, විමසුම් ප්‍රශස්තකරණය මත පදනම්ව, ඒවා යන්ත්‍රයට සමාන අර්ථයක් තිබිය හැකිය.

ඔබ සැමවිටම කියවිය හැකි පරිදි කේත කළ යුතුය.

එනම්, මෙය ගොඩනඟන ලද සම්බන්ධතාවයක් නම්, පැහැදිලි සම්බන්ධය භාවිතා කරන්න. ඔබ දුර්වල ලෙස සම්බන්ධ දත්ත සමඟ ගැලපෙන්නේ නම්, එහිදී වගන්තිය භාවිතා කරන්න.

— ජෝන් ගීට්සන්
source

11

SQL: 2003 ප්‍රමිතිය සමහර ප්‍රමුඛතා නීති වෙනස් කර ඇති නිසා JOIN ප්‍රකාශයක් “කොමා” සම්බන්ධතාවයට වඩා ප්‍රමුඛස්ථානය ගනී. මෙය සැබවින්ම ඔබගේ විමසුමේ ප්‍රති results ල එය සකසන ආකාරය අනුව වෙනස් කළ හැකිය. MySQL 5.0.12 ප්‍රමිතියට අනුගත වීම සඳහා මාරු වූ විට මෙය සමහර අයට ගැටළු ඇති කරයි.

එබැවින් ඔබේ උදාහරණයේ දී, ඔබේ විමසීම් එකම ආකාරයකින් ක්‍රියාත්මක වේ. නමුත් ඔබ තුන්වන වගුවක් එකතු කළේ නම්: තෝරන්න ... වගුව 1 සිට, වගුව 2 වගුවට සම්බන්ධ වන්න ... කොහෙද ...

MySQL 5.0.12 ට පෙර, table1 සහ table2 පළමුව සම්බන්ධ වේ, පසුව table3. දැන් (5.0.12 සහ මත), වගුව 2 සහ වගුව 3 පළමුව සම්බන්ධ වේ, පසුව වගුව 1. එය සැමවිටම ප්‍රති results ල වෙනස් නොකරයි, නමුත් එයට එය කළ හැකි අතර ඔබ එය නොදැන සිටිය හැකිය.

මම කිසි විටෙකත් "කොමා" සින්ටැක්ස් භාවිතා නොකරමි, ඔබේ දෙවන උදාහරණය තෝරා ගනිමි. කෙසේ වෙතත් එය තව බොහෝ කියවිය හැකි ය, JOIN කොන්දේසි JOIN සමඟ ඇත, වෙනම විමසුම් අංශයකට වෙන් නොකෙරේ.

— බ්‍රෙන්ට් බයිස්ලි
source

සම්මත SQL වෙනස් නොවීය. MySQL වැරදියි, දැන් හරි. MySQL අත්පොත බලන්න.

— philipxy

4

ඔබ MySQL ගැන කතා කරන බව මම දනිමි, කෙසේ වෙතත්: ඔරකල් 9 හි පැහැදිලි සම්බන්ධතා හා ව්‍යංග බැඳීම් විවිධ ක්‍රියාත්මක කිරීමේ සැලසුම් ජනනය කරනු ඇත. ඔරකල් 10+ හි විසඳා ඇති AFAIK: තවදුරටත් එවැනි වෙනසක් නොමැත.

— ජොආනෝ මාකස්
source

2

ඔබ බොහෝ විට ගතික ගබඩා කළ ක්‍රියා පටිපාටි ක්‍රමලේඛනය කරන්නේ නම්, ඔබ ඔබේ දෙවන උදාහරණයට (කොතැනද භාවිතා කරමින්) ආදරයෙන් බැඳෙනු ඇත. ඔබට විවිධ ආදාන පරාමිතීන් සහ මෝෆ් අවුල් ගොඩක් තිබේ නම්, එය එකම ක්‍රමයයි. එසේ නොමැතිනම් ඔවුන් දෙදෙනාම එකම විමසුම් සැලැස්මක් ක්‍රියාත්මක කරනු ඇත, එබැවින් අනිවාර්යයෙන්ම සම්භාව්‍ය විමසුම් වල පැහැදිලි වෙනසක් නොමැත.

— ක්විස් මැජ්ස්ටර්
source

1

ANSI join syntax අනිවාර්යයෙන්ම වඩා අතේ ගෙන යා හැකි ය.

මම මයික්‍රොසොෆ්ට් SQL සේවාදායකයේ උත්ශ්‍රේණිගත කිරීමක් හරහා යන අතර, SQL සේවාදායකයේ පිටත සම්බන්ධ වීම සඳහා වන = * සහ * = සින්ටැක්ස් 2005 වර්ග සේවාදායකය සඳහා සහ පසුව (අනුකූලතා මාදිලියකින් තොරව) සහය නොදක්වන බව ද සඳහන් කරමි.

— බෙන්සෝ
source

2

SQL Server 2000 හි පවා, = සහ = වැරදි ප්‍රති results ල ලබා දිය හැකි අතර එය කිසි විටෙකත් භාවිතා නොකළ යුතුය.

— HLGEM

2

*=හා =*ANSI කිසි දිනෙක හොඳ අංකනය විය. ON අවශ්‍ය වූයේ එබැවිනි - උපසිරැසි නොමැති විට බාහිර සම්බන්ධතා සඳහා (ඒවා එකවර එකතු කරන ලදි, එබැවින් ඒවා ඇත්ත වශයෙන්ම CROSS සහ INNER JOINs හි අවශ්‍ය නොවේ.)

— ෆිලිප්සි

INNER JOIN ON vs vs වගන්තිය

තාර්කික විමසුම් සැකසුම් අවධීන් පිළිබඳ කෙටි විස්තරයක්