السلام عليكم بنا يجازيك خير , حظرتك لو في فرق ولو بسيط بين اني في sql query احدد outer او left انه يكون هو الاصغر او عكس ذالك بما ان احظرتك استاذ وضحت لنا ان الامر لا فرق فيه في execution plan ولكن حسب فهمي انه ال initial plan راح يكون حسب sql query فهل كونه معرفتي انه افظل شيء من ناحية cost راح يكون ليه تأثير في عدد plans الي راح يقارن بينها او الوقت المتخذ ل query optimizer انه يحدد final plan
ده بيعتمد على كل optimizer وايه الtransformations اللى بيعملها على الplan. نظريا لو الoptimizer مثالى فالمفروض مايفرقش تكتب الquery ازاي لأن هو هيجرب كل الplans الممكنة. لكن في الواقع طبعا مفيش optimizer مثالي وطريقة كتابة الquery بتحدد الinitial plan وممكن يكون ليها تأثير على ايه الplans التانية اللى يقارن بينها
I have a question about merge joins. Does it work only when the outer table join key is not unique? Because at minute 24, I can't see how it would work if there were multiple rows on the R with the same join key/id.
Great question!! Merge join works regardless of whether the outer join key is unique or not. The way this works is as follows: both sides are sorted, right. So, whenever the inner pointer is advanced, if it finds a "new" value, it will keep track of the first location of this new value (and the first location of the previous value). When the outer side is advanced, if it still has the same value, then the inner pointer is "backtracked" to start again at that first location. So, basically you can think of it as doing a mini- nested loop join for the set of the rows that have the same join key on both sides. Does that make sense?
why when adding order by t.a the join algorithm change هو مش المفروض انه الداتا مترتبة اصلا كدا كدا لانه معمول index فكدا كدا الداتا فى ال input جياله مترتبة بال index
كون أن فيه index على column معين ده مش معناه اني لما بعمل sequential scan أن الداتا هترجع مترتبة. الكلام ده يكون صحيح في حالة واحدة لو الindex ده كان clustered index. انما لو index عادى أو non clustered يبقى الdata هترجع مترتبة بس لو عملت index scan مش في حالة ال sequential scan.
طيب ياودكتور انا متلخبط جدا دلوقت ، هو ايه الفرق بين ال sloted و ال logged و ال index , و ال hash index و b tree و ال composit index هل ممكن نقول ان اللي فوق طريقة تخزين ال data دخل ال page اما ال hash index و ال b tree دول طريقة تخزين و الوصول لل index نفسه ؟؟؟؟؟
لما تبص على الdatabase انت عندك tables و ممكن يكون عندك indexes. البيانات اللى فى الtables هى البيانات الأساسية و بتكون متخزنة بطريقة من الطرق اللى فوق. اذا كان عندك indexes فدول عبارة عن data structures بيسهلوا الوصول للبيانات اللى فى الtables بدل ما تضطر انك كل مرة تعمل full table scan والindexes دول بيكونوا على هيئة hash index أو btree كل index من دول لو كان على اكتر من column/attributes بنسميه composite index ياترى وضحت كده؟
@@TechVault_ يعني ال hash index او ال btree او ال composit ده data structre لتخزين و للوصوا لل index نفسه اللي منه اقدر اوصل لل data اللي داخل ال page سواء كانت متخزنة بال index او ال slot او ال logged .
