Let's talk about CROSS JOIN. What it is. What it most definitely is not. It is useful. It's not a conditional many-to-many join. The main thing -- the dangerous thing, usually -- about cross joins is that they form the Cartesian product of two tables. That is, every row in the left-hand table is matched to every row in the right-hand table. The number of rows in the outcome is the product of the number of rows in the two tables. CROSS JOIN is syntactic sugar. You can accomplish this by using a different join type. These are the same: SELECT a.*, b.* FROM a FULL OUTER JOIN b ON TRUE; SELECT a.*, b.* FROM a CROSS JOIN b; I've seen cross joins proposed as a method of "finding all pairs of football matches played" or "finding all pairs of cities with flights between them". For little examples like this, the output looks correct, because you're wanting a dense outcome set. But imagine two tables with 1 million (1,000,000) rows each. The product of these will have 1 trillion (1,000,000,000,000) rows, right around 125 rows for each person alive today. If you want non-dense many-to-many matches, use an INNER JOIN with your many-to-many bridging table. If your rows have arrays of matches (instead of a bridging table), use a LATERAL JOIN first to expand these rows. (LATERAL JOIN is written as an UNNEST in some SQL variants.) So what's a CROSS JOIN good for? (1) Widening rows with additional information. (2) Providing an exhaustive list of widened rows. One of the tables should be tiny, and contain columns relevant to every row of your other table. Consider a 1-row table. All it contains is a pair of timestamps, and you want to apply these timestamps to every row of your main table. CROSS JOIN is great for this. Your number of rows is unchanged, and you get your extra columns. Or consider a case where you've moved from having 1 warehouse of products to having 3, and you want to add a warehouse location to each row of your product catalog. A CROSS JOIN of your product catalog and your (very short) list of warehouses will do this immediately.
Chad Musick’s Post
More Relevant Posts
-
My 59th blog is about how to sort the fields by your own order list. Actually, I posted this way as macro to the Community Gallery. However you can know how to update Raw XML with formula by Action tool in my post. This is advanced way and it is worth to learn it. Please check my blog. #alteryx https://lnkd.in/gzXVSmUy
To view or add a comment, sign in
-
🚀 𝐒𝐐𝐋 𝐐𝐮𝐞𝐫𝐲 𝐢𝐧 𝐀𝐜𝐭𝐢𝐨𝐧: 𝐅𝐢𝐥𝐭𝐞𝐫𝐢𝐧𝐠 𝐛𝐲 𝐒𝐞𝐥𝐥𝐞𝐫 𝐑𝐚𝐭𝐢𝐧𝐠! 🚀 Just wrapped up a cool SQL query for a web shop scenario! I had two tables: Sellers and Items, where each item is linked to a seller. The goal was to select only those items where the seller had a rating greater than 4 ⭐. Here's how I approached it(see the image below) 👉This query returned the item name and the seller name for items belonging to sellers with a top-notch rating! 👉It’s fascinating how SQL can help connect and filter data effortlessly, allowing businesses to keep track of their high-quality sellers and the products they offer. Thanks to Pragya mam #SQL #DataAnalysis #SQLQueries #DataInsights #WebShop #SellersAndItems #TechSkills #LearningByDoing
To view or add a comment, sign in
-
-
𝗦𝗤𝗟 𝗗𝗮𝘁𝗮 𝗧𝘆𝗽𝗲𝘀 𝗢𝘃𝗲𝗿𝘃𝗶𝗲𝘄 𝗜𝗡𝗧 (𝗜𝗻𝘁𝗲𝗴𝗲𝗿) Used to store whole numbers, both positive and negative, such as 10, -25, or 2000. Commonly applied for storing counts, IDs, or numeric values without decimals. 𝗩𝗔𝗥𝗖𝗛𝗔𝗥 (𝗩𝗮𝗿𝗶𝗮𝗯𝗹𝗲 𝗖𝗵𝗮𝗿𝗮𝗰𝘁𝗲𝗿) Handles text of variable length like “John” or “Product123.” Ideal for names, descriptions, or any text where the size varies. 𝗗𝗔𝗧𝗘 Captures calendar dates in formats like YYYY-MM-DD (e.g., 2024-11-16). Perfect for birthdates, order dates, or event dates. 𝗕𝗢𝗢𝗟𝗘𝗔𝗡 Stores TRUE or FALSE values (or equivalent 1/0). Useful for flags like “Is Active?” or “Payment Completed?” 𝗗𝗘𝗖𝗜𝗠𝗔𝗟 (𝗼𝗿 𝗡𝗨𝗠𝗘𝗥𝗜𝗖) Holds precise numeric values with fixed decimal points, such as 99.99 or -10.75. Often used for monetary values or measurements requiring precision. [Explore More In The Post] Follow Yogesh Tyagi for more such information and don’t forget to save this post for later hashtag #sql hashtag #sqlserver hashtag #sqldatabase hashtag #sqldeveloper hashtag #sqlqueries
To view or add a comment, sign in
-
-
I've been diving deeper into SQL and discovered something new and interesting to me: the difference between RANK() and DENSE_RANK() window functions. I was only aware of RANK(), but skipping ranking after ties bothered me. Here's a concise example of employees and their revenue contributions to the company: | employee_id | employee_name | revenue | | 1 | Alice | 5000 | | 2 | Bob | 7000 | | 3 | Charlie | 7000 | | 4 | David | 6000 | | 5 | Eva | 5000 | ------------------------------------------------------ Consider this query: SELECT employee_id, employee_name, revenue, RANK() OVER (ORDER BY revenue DESC) AS rank, DENSE_RANK() OVER (ORDER BY revenue DESC) AS dense_rank FROM employees; It provides us the result set of: | id | name | revenue | rank | dense_rank | 2 | Bob | 7000 | 1 | 1 | 3 | Charlie | 7000 | 1 | 1 | 4 | David | 6000 | 3 | 2 | 1 | Alice | 5000 | 4 | 3 | 5 | Eva | 5000 | 4 | 3 Do you see the difference? In this example, RANK() skips ranks after ties, whereas DENSE_RANK() does not. Understanding these differences can be crucial.
To view or add a comment, sign in
-
-
Users tell us that they love how little space ClickHouse takes to store data. And guess what? In the 24.6 release, we’ve made it even better! Read our latest blog post to learn more about the optimal table-sorting feature that makes this happen. This release also sees a beta release of chDB, our in-process SQL engine, and functions for Hilbert Curves. https://lnkd.in/ejP3xB-3
ClickHouse Release 24.6
clickhouse.com
To view or add a comment, sign in
-
Hey LinkedIn community! Ever wondered about the difference between controlled and uncontrolled components in React? Let's dive into it! 🏊♂️ 🌟 Controlled Components Controlled components have their state managed by React, making data flow from the component state to the input field and back via event handlers. This provides real-time validation and more control over form data. Perfect for complex forms! 💪 Example: __jsx__ import React, { useState } from 'react'; function ControlledComponent() { const [value, setValue] = useState(''); const handleChange = (event) => { setValue(event.target.value); }; return ( <input type="text" value={value} onChange={handleChange} /> ); } 🌟 Uncontrolled Components Uncontrolled components manage their state internally within the DOM. Data flows directly between the DOM and the input field, accessed using refs. They are simpler and can be handy for less complex scenarios. 👍 Example: __jsx__ import React, { useRef } from 'react'; function UncontrolledComponent() { const inputRef = useRef(null); const handleSubmit = (event) => { event.preventDefault(); alert(`Input value: ${inputRef.current.value}`); }; return ( <form onSubmit={handleSubmit}> <input type="text" ref={inputRef} /> <button type="submit">Submit</button> </form> ); } Both approaches have their place. Choose controlled components for greater control and real-time validation, and opt for uncontrolled components for simplicity. Got any thoughts or experiences to share? Let's discuss in the comments! 💬
To view or add a comment, sign in
-
-
2️⃣ LEFT JOIN (or LEFT OUTER JOIN) 𝐖𝐡𝐚𝐭 𝐢𝐭 𝐝𝐨𝐞𝐬: ↳ Returns all rows from the left table and the matching rows from the right table. If no match is found, it fills with NULL. 𝐔𝐬𝐞 𝐜𝐚𝐬𝐞: ↳ When you need all the data from the left table, regardless of whether there’s a match in the right table. 𝐄𝐱𝐚𝐦𝐩𝐥𝐞: If you want a list of all customers and their orders (even if some haven’t placed any), use a LEFT JOIN. 3️⃣ RIGHT JOIN (or RIGHT OUTER JOIN) 𝐖𝐡𝐚𝐭 𝐢𝐭 𝐝𝐨𝐞𝐬: ↳ Returns all rows from the right table and the matching rows from the left table. If no match is found, it fills with NULL. 𝐔𝐬𝐞 𝐜𝐚𝐬𝐞: ↳ When you need all the data from the right table, regardless of whether there’s a match in the left table. 𝐄𝐱𝐚𝐦𝐩𝐥𝐞: If you want a list of all orders and the customers who placed them (even if some orders don’t have customer details), use a RIGHT JOIN. 4️⃣ FULL JOIN (or FULL OUTER JOIN) 𝐖𝐡𝐚𝐭 𝐢𝐭 𝐝𝐨𝐞𝐬: ↳ Returns all rows from both tables. ↳ Where there’s no match, it fills with NULL. 𝐔𝐬𝐞 𝐜𝐚𝐬𝐞: ↳ When you want everything—matches from both tables and unmatched rows from each table. 𝐄𝐱𝐚𝐦𝐩𝐥𝐞: If you want a complete list of customers and orders, even if some customers haven’t placed orders or some orders don’t have customer details, use a FULL JOIN. 𝐕𝐢𝐬𝐮𝐚𝐥𝐢𝐳𝐢𝐧𝐠 𝐭𝐡𝐞 𝐉𝐨𝐢𝐧𝐬 Imagine two overlapping circles (tables): 𝟏. 𝐈𝐍𝐍𝐄𝐑 𝐉𝐎𝐈𝐍 → The middle part (where circles overlap). 𝟐. 𝐋𝐄𝐅𝐓 𝐉𝐎𝐈𝐍 → Everything in the left circle, plus matches in the right. 𝟑. 𝐑𝐈𝐆𝐇𝐓 𝐉𝐎𝐈𝐍 → Everything in the right circle, plus matches in the left. 𝟒. 𝐅𝐔𝐋𝐋 𝐉𝐎𝐈𝐍 → Everything in both circles, matches or not.
To view or add a comment, sign in
-
-
We're back with this week's Wrap of what's new (and what's better) in Equals. New We’re listening to your feedback and fine-tuning the querying experience: • Headers are now restyled to more clearly identify queried output (purple), calculated columns (green), and data notes (yellow) • We’ve improved datasource joins to make each step more intuitive • We've streamlined the process of adding and removing filters on connected sheets Improved • You'll find links to relevant datasources from the schema overview in the table browser Fixed • You can now add an OR criteria after several ANDs in query builder filters And that's your Wrap! See you next week—same time, same place.
To view or add a comment, sign in
-
-
𝐒𝐐𝐋 𝐉𝐨𝐢𝐧𝐬 𝐄𝐱𝐩𝐥𝐚𝐢𝐧𝐞𝐝: 𝐇𝐨𝐰 𝐭𝐨 𝐌𝐞𝐫𝐠𝐞 𝐓𝐚𝐛𝐥𝐞𝐬 𝐄𝐟𝐟𝐢𝐜𝐢𝐞𝐧𝐭𝐥𝐲 𝐈𝐍𝐍𝐄𝐑 𝐉𝐎𝐈𝐍: This type of join returns only the rows where there is a match between the tables. Think of it as combining data where there is a common link. 𝐋𝐄𝐅𝐓 𝐉𝐎𝐈𝐍 (𝐨𝐫 𝐋𝐄𝐅𝐓 𝐎𝐔𝐓𝐄𝐑 𝐉𝐎𝐈𝐍): This join returns all the rows from the left table, and the matching rows from the right table. If there's no match, it includes the left table’s row with NULLs for columns from the right table. 𝐑𝐈𝐆𝐇𝐓 𝐉𝐎𝐈𝐍 (𝐨𝐫 𝐑𝐈𝐆𝐇𝐓 𝐎𝐔𝐓𝐄𝐑 𝐉𝐎𝐈𝐍): This join returns all the rows from the right table, and the matching rows from the left table. If there's no match, it includes the right table’s row with NULLs for columns from the left table. 𝐅𝐔𝐋𝐋 𝐉𝐎𝐈𝐍 (𝐨𝐫 𝐅𝐔𝐋𝐋 𝐎𝐔𝐓𝐄𝐑 𝐉𝐎𝐈𝐍): This join returns all rows when there is a match in either the left or right table. If there is no match, it includes rows from both tables with NULLs where there are no matches. 𝐂𝐑𝐎𝐒𝐒 𝐉𝐎𝐈𝐍: This join returns the Cartesian product of both tables, meaning every row from the first table is combined with every row from the second table. Like this post if you need more 👍❤️ I hope it helps :)
To view or add a comment, sign in
-