Master Ruby on Rails Queries: A Complete Guide with Best Practices and SQL Equivalents

Active Record is one of the most powerful features of Ruby on Rails, enabling seamless interaction with the database using an intuitive, Ruby-like syntax. One such common query is User.all. Let’s dive into its details, use cases, and alternatives.

1. Detail

User.all is an Active Record method that retrieves all records from the users table.
It generates an array-like object of User model instances, where each instance represents a row in the database table.

2. Equivalent to Raw SQL Query

When executed, User.all translates to the following SQL query:

SELECT "users".* FROM "users";

This query fetches all columns (*) from the users table.

3. When and Where We Use It

• Fetching all records:
  Use User.all when you need to retrieve all user records from the database.
• Preloading Data:
  Often used when preloading associated data in small datasets. For example:rubyCopy User.all.includes(:posts)
• For Small Datasets Only:
  Use it for datasets you know are manageable in memory.

4. When We Don’t Want to Use It

• Large Datasets:
  Fetching all records from a large database table can lead to performance issues as it loads all records into memory.
• Pagination or Filtering Required:
  Avoid User.all when only a subset of data is required. Use methods like limit, where, or order instead: User.where(active: true).limit(10).order(:created_at)
  
• Database Operations:
  Don’t use User.all for operations like counting. Instead, use optimized methods:rubyCopy User.count # Efficient

5. More Examples

• Retrieve Active Users: User.where(status: 'active')
• Retrieve and Sort by Creation Date: User.all.order(created_at: :desc)
• Preload Associations: User.all.includes(:posts, :comments)

6. Questions and Answers

Q1: What does User.all return?
A1: It returns an ActiveRecord::Relation object containing all records from the users table.

Q2: Is User.all lazy-loaded?
A2: Yes, User.all doesn’t immediately hit the database. The query is executed

Case Study: Using User.all in a Real-World Scenario

Scenario

A company is building an admin dashboard to display all registered users in a table. Initially, they implemented the following query:

@users = User.all

Challenges

1. Performance Issues:
   As the user base grew to thousands, loading all users into memory caused delays and high memory usage.
2. Unnecessary Data Retrieval:
   The admin page only required specific fields like name, email, and role, but User.all fetched all columns.
3. Lack of Pagination:
   Displaying all users on one page was overwhelming and caused the frontend to crash due to large payloads.

Solution

The team optimized the query to:

1. Fetch only necessary fields using select: @users = User.select(:name, :email, :role)
2. Implement pagination with kaminari: @users = User.page(params[:page]).per(20)
3. Add sorting: @users = User.order(:created_at)

Results

• Improved Performance: Reduced memory usage and faster response times.
• Better User Experience: Pagination made the data easier to navigate.
• Focused Query: Only the required fields were fetched, reducing database load.

This case study illustrates how User.all is suitable for small datasets but must be optimized for production-scale applications.

Active Record in Rails provides a high-level interface for database queries. One of the commonly used queries is User.first, which retrieves the first record from the users table. This post covers its details, use cases, alternatives, and optimisation tips.

1. Detail

User.first fetches the first record from the users table, based on the table’s default order (usually the primary key, id). It returns a single User object or nil if no record exists.

2. Equivalent to Raw SQL Query

When executed, User.first translates to the following SQL query:

SELECT "users".* FROM "users" ORDER BY "users"."id" ASC LIMIT 1;

This query:

1. Orders the table by the id column in ascending order.
2. Limits the result to one record.

3. When and Where We Use It

• Fetch the First Record:
  Retrieve the first record in the table for initialization or testing:rubyCopy codefirst_user = User.first
• Default Configuration or System Initialization:
  When the first record represents a default configuration or a baseline for other operations.
• Debugging and Development:
  Quickly retrieve the first record for checking data integrity.

4. When We Don’t Want to Use It

• Large Datasets:
  Avoid using User.first when the table contains a large number of records, as ordering by id can be expensive.
• Custom Ordering:
  If the “first” record based on specific criteria (e.g., date or name) is needed, use order: User.order(:created_at).first
• When Multiple Queries are Needed:
  For fetching more than one record, consider using limit: User.limit(10)

5. More Examples

• Fetching First Active User: User.where(active: true).first
• Fetching First User Ordered by Name: User.order(:name).first
• Fetching First User with Preloaded Associations: User.includes(:posts).first

6. Questions and Answers

1. Q: What does User.first return if no records exist?
   A: It returns nil.
2. Q: How can we get the first record based on a different column?
   A: Use order: User.order(:created_at).first
3. Q: Is User.first efficient for large datasets?
   A: Not always. Use indexed columns for better performance.

7. Case Study

Scenario:
A Rails app needs to fetch the first registered user as the default admin during system initialization. Initially, the team implemented:

admin_user = User.first

Problem:
The query relied on the default id order, which was unreliable after manual database changes. This led to incorrect user assignments.

Solution:
They optimized the query to fetch the first user based on creation date:

admin_user = User.order(:created_at).first

Result:
The query became consistent, always returning the true first registered user.

8. Alternative

Instead of User.first, use the following depending on the use case:

• Fetch First Based on Criteria: User.where(role: 'admin').first
• Custom Ordering: User.order(:created_at).first
• Use SQL Directly (Raw Query): User.find_by_sql("SELECT * FROM users ORDER BY created_at ASC LIMIT 1")

9. How to Optimize It

1. Add an Index:
   Ensure the column used for ordering (e.g., id or created_at) has an index to speed up query execution.
2. Use Scopes:
   Define a scope for frequently used criteria: scope :first_active_user, -> { where(active: true).order(:created_at).first }
3. Cache Results for Repeated Queries:
   Cache the first record if it’s frequently accessed: Rails.cache.fetch('first_user') { User.first }

10. Case Study in Summarized Way

Scenario:
A team used User.first to fetch the first registered user in their app. However, after database maintenance, User.first returned the wrong user.

Solution:
They modified the query to order by created_at:

User.order(:created_at).first

Result:
The query consistently fetched the correct first user, improving reliability and user assignment accuracy.

This post provides a comprehensive understanding of User.first and how to use it effectively in a Rails application.

Active Record in Rails simplifies database queries into Ruby-like syntax. One such frequently used query is User.last. This post dives into the details of User.last, its use cases, alternatives, and optimisation strategies.

1. Detail

User.last fetches the last record from the users table based on the primary key (id) order.
It returns a single instance of the User model.

2. Equivalent to Raw SQL Query

User.last translates into the following SQL query:

SELECT "users".* FROM "users" ORDER BY "users"."id" DESC LIMIT 1;

This query orders the users table by id in descending order and fetches the first record from the result.

3. When and Where We Use It

• Retrieving the Latest Entry by ID:
  Use User.last when you need the most recently added user (based on the id order).
• Debugging or Testing:
  Useful during development to quickly check the last added record.
• For Small Datasets:
  Ideal when the table has a manageable number of rows and doesn’t require further filtering.

4. When We Don’t Want to Use It

• Large Datasets Without Indexing:
  If the id field isn’t indexed, fetching the last record can lead to performance bottlenecks.
• Custom Sorting:
  Avoid using User.last when you need the last record based on a custom field (e.g., created_at). Use.order instead: User.order(:created_at).last
• Bulk Data Processing:
  When processing large datasets, fetching only the last record might not align with your needs.

5. More Examples

• Basic Usage: user = User.last
• Retrieve Last Active User: last_active_user = User.where(active: true).last
• Order by Custom Field and Get Last Record: last_created_user = User.order(:created_at).last
• Chaining With Includes: last_user_with_posts = User.includes(:posts).last

6. Questions and Answers

1. Q: Does User.last fetch all records before retrieving the last one?
   A: No, Active Record uses LIMIT 1 with descending order, optimizing the query.
2. Q: What happens if the table is empty?
   A: User.last returns nil.
3. Q: Can we use User.last with scopes or filters?
   A: Yes, you can combine it with other Active Record methods: User.where(role: "admin").last
4. Q: Is User.last suitable for real-time performance-sensitive tasks?
   A: Not for large datasets or tables without proper indexing.

7. Case Study

Scenario:
An e-commerce platform uses User.last to retrieve the latest registered user for an admin dashboard widget. As the user base grew, the query started causing delays.

Challenges:

1. Fetching data without a specific order occasionally retrieved incorrect results.
2. The query became slow with a growing dataset.

Solution:
The team optimized the query by:

1. Adding an index to the id field.
2. Switching to User.order(:created_at).last for accurate results.

Results:

• Reduced query time significantly.
• Improved accuracy for fetching the latest user based on created_at.

8. Alternative

• order and limit:
  Explicitly define order and limit: User.order(:created_at).last
• Custom Scope:
  Define a reusable scope for flexibility: scope :latest, -> { order(created_at: :desc).limit(1) }
User.latest

9. How to Optimize It

1. Indexing:
   Ensure the id or the field used for ordering (e.g., created_at) is indexed.
2. Avoid Loading Unnecessary Data:
   Use select to retrieve only the required fields: User.select(:id, :name).order(:created_at).last
3. Pagination for Related Use Cases:
   Instead of fetching a single record repeatedly, implement pagination for scalability.

10. Case Study (Summarized)

Scenario:
A SaaS platform used User.last to display the most recently registered user. Performance issues arose as the dataset grew.

Solution:
The team:

1. Indexed the id column for faster lookups.
2. Replaced User.last with User.order(:created_at).last for consistency.

Outcome:
Query time improved, and results were accurate, even for large datasets.

Active Record makes database interaction simple in Rails. One common query is User.find(1), which is used to retrieve a specific record by its primary key. Let’s explore this query in detail, including its use cases, alternatives, and optimisations.

1. Detail

User.find(1) retrieves a single record from the users table with the primary key (id) value of 1.
It raises an ActiveRecord::RecordNotFound error if the record does not exist.

2. Equivalent to Raw SQL Query

When executed, User.find(1) translates to:

SELECT "users".* FROM "users" WHERE "users"."id" = 1 LIMIT 1;

This query fetches all columns (*) from the users table where id = 1.

3. When and Where We Use It

• Fetching a Specific Record by ID:
  Use User.find(1) when you know the exact id of the record to retrieve.
• Retrieving Associated Data:
  Combine with associations to fetch related data: user = User.find(1) user.posts
• Debugging or Development:
  Handy for testing or inspecting specific records during development.

4. When We Don’t Want to Use It

• Uncertain ID:
  Avoid User.find(1) when you are unsure if the record exists. Use find_by or where instead to avoid raising errors: User.find_by(id: 1)
• Bulk Queries:
  If you need multiple records, avoid find and use methods like where or find_by_ids.
• Sensitive APIs:
  For APIs or user inputs, validate the id to prevent misuse: User.find(params[:id]) # Can raise errors if the ID is invalid

5. More Examples

• Basic Usage: user = User.find(1)
• Find a Record and Update It: user = User.find(1)
user.update(name: "John Doe")
• Find Multiple Records: users = User.find([1, 2, 3])
• Handle Exceptions: begin user = User.find(1) rescue ActiveRecord::RecordNotFound puts "User not found" end

6. Questions and Answers

1. Q: What happens if the record does not exist?
   A: User.find(1) raises an ActiveRecord::RecordNotFound error.
2. Q: Can find fetch multiple records?
   A: Yes, you can pass an array of IDs: User.find([1, 2, 3])
3. Q: How is find different from find_by?
   A: find requires an ID and raises an error if the record is not found, while find_by allows custom conditions and returns nil if no record is found: User.find_by(id: 1)
4. Q: Is find performant for large tables?
   A: Yes, but it assumes the id is indexed.

7. Case Study

Scenario:
A startup implemented User.find(1) in their API to fetch user details by ID. As the database grew, they faced issues when invalid IDs were passed.

Challenges:

1. Raised errors when IDs did not exist.
2. Inefficient for large datasets without proper error handling.

Solution:

1. Replaced find with find_by for more graceful error handling: user = User.find_by(id: params[:id])
2. Added validations to sanitize user input: user = User.find_by(id: params[:id]) if params[:id].to_i > 0

Results:

• API became more robust and error-free.
• User experience improved due to graceful handling of missing records.

8. Alternative

• Using find_by:
  Avoid errors for missing records: user = User.find_by(id: 1)
• Using where:
  Return an ActiveRecord::Relation instead of a single object: user = User.where(id: 1).first
• Custom Scopes:
  Define reusable scopes for flexibility: scope :by_id, ->(id) { where(id: id) } User.by_id(1)

9. How to Optimize It

1. Index the Primary Key:
   Ensure the id column is indexed for fast lookups.
2. Handle Errors Gracefully:
   Wrap find in a rescue block or use find_by to avoid exceptions: user = User.find_by(id: params[:id]) || raise "User not found"
3. Avoid Loading Unnecessary Data:
   Use select to retrieve specific fields: user = User.select(:id, :name).find(1)
4. Paginate for Larger Queries:
   Combine with pagination for scalable APIs: users = User.order(:id).limit(10).offset(20)

10. Case Study (Summarized)

Scenario:
An e-commerce platform used User.find(1) to fetch user details. As the user base grew, they faced errors when invalid IDs were passed.

Solution:

1. Replaced find with find_by for better error handling.
2. Validated input IDs to prevent misuse.
3. Indexed the id column for faster queries.

Outcome:

Enhanced user experience with graceful error handling.

Improved API stability and performance.

Active Record in Rails makes working with databases seamless and intuitive. The query User.find_by(email: 'example@example.com') is a common and efficient way to find a record by a specific attribute. In this post, we’ll cover its details, use cases, optimizations, and more.

1. Detail

User.find_by(email: 'example@example.com') retrieves the first record from the users table where the email column matches 'example@example.com'.
If no record matches, it returns nil instead of raising an error, making it safer than find.

2. Equivalent to Raw SQL Query

The query translates to:

SELECT "users".* FROM "users" WHERE "users"."email" = 'example@example.com' LIMIT 1;

This fetches all columns (*) from the users table where the email is equal to 'example@example.com', limiting the result to one record.

3. When and Where We Use It

• Finding Records by Attributes:
  Use it when you need to fetch a record by a specific attribute such as email, username, or token.
• Graceful Handling of Missing Records:
  find_by is ideal for cases where the absence of a record is acceptable, as it returns nil instead of raising an error.
• Frequently Used in Authentication:
  A common use case is finding users by email during the login process: user = User.find_by(email: params[:email])

4. When We Don’t Want to Use It

• Fetching Multiple Records:
  Avoid find_by if you need to retrieve all matching records. Use where instead: User.where(email: 'example@example.com')
• When Record Absence Must Be Handled:
  If a missing record should trigger an exception, use find_by!: User.find_by!(email: 'example@example.com')
• For Complex Queries:
  When multiple conditions or custom SQL are required, where is more flexible: User.where("email = ? AND active = ?", 'example@example.com', true)

5. More Examples

• Basic Usage: user = User.find_by(email: 'example@example.com')
• With Multiple Conditions: user = User.find_by(email: 'example@example.com', active: true)
• Handle Missing Records Gracefully: user = User.find_by(email: 'nonexistent@example.com') || "User not found"
• Using find_by! to Raise an Error if Not Found: user = User.find_by!(email: 'example@example.com')

6. Questions and Answers

1. Q: What happens if no record matches the query?
   A: User.find_by returns nil.
2. Q: How is find_by different from find?
   A: find searches by primary key (id) and raises an error if no record is found, whereas find_by searches by attribute(s) and returns nil if no record is found.
3. Q: Can we combine find_by with scopes?
   A: Yes, find_by can be used with scopes: User.active.find_by(email: 'example@example.com')
4. Q: Does find_by fetch multiple records?
   A: No, it fetches only the first matching record. Use where to retrieve multiple records.

7. Case Study

Scenario:
A SaaS application used User.find_by(email: params[:email]) to authenticate users during login. Occasionally, users would enter incorrect email addresses.

Challenges:

1. Missing records returned nil, causing a NoMethodError when methods were called on nil.
2. High response times when searching for unindexed attributes.

Solution:

1. Added proper handling for nil records: user = User.find_by(email: params[:email]) if user.nil? render json: { error: "User not found" } end
2. Indexed the email column to improve query performance: add_index :users, :email

Results:

• Reduced query response time significantly.
• No runtime errors due to missing records.

8. Alternative

• Using find_by!:
  Raises an error when no record is found: user = User.find_by!(email: 'example@example.com')
• Using where with first:
  More explicit but functionally equivalent: user = User.where(email: 'example@example.com').first
• Defining a Scope:
  Reusable query for finding users by email: scope :by_email, ->(email) { where(email: email).limit(1) } user = User.by_email('example@example.com').first

9. How to Optimize It

1. Index the Search Column:
   Add an index to the email column to speed up lookups: add_index :users, :email
2. Fetch Only Necessary Fields:
   Use select to retrieve specific columns: user = User.select(:id, :email).find_by(email: 'example@example.com')
3. Graceful Handling for Missing Records:
   Always check for nil when using find_by: user = User.find_by(email: params[:email]) render json: { error: "User not found" } unless user
4. Avoid N+1 Queries:
   Preload associations when fetching related data: user = User.includes(:posts).find_by(email: 'example@example.com')

10. Case Study (Summarised)

Scenario:
A company used User.find_by(email: 'example@example.com') to retrieve users during login. As the user base grew, performance issues arose, and handling nil records became a challenge.

Solution:

1. Indexed the email column for faster queries.
2. Added proper handling for nil to prevent runtime errors.
3. Used select to fetch only required fields.

Outcome:

Lowered memory usage by fetching only required data.

Reduced query time.

Improved user experience with better error handling.

Active Record in Rails simplifies querying databases with an intuitive syntax. The query User.where(active: true) is widely used to filter records based on a condition. Let’s explore its details, use cases, and optimizations.

1. Detail

User.where(active: true) retrieves all records from the users table where the active column is true.
It returns an ActiveRecord::Relation object, which can be further chained with other queries.

2. Equivalent to Raw SQL Query

The query translates to:

SELECT "users".* FROM "users" WHERE "users"."active" = true;

This fetches all columns (*) from the users table where the active column is true.

3. When and Where We Use It

• Filtering Records Based on Conditions:
  Use it when you need to filter records by specific attribute values, such as active users: User.where(active: true)
• Chaining Queries:
  Combine with other queries for more complex conditions: User.where(active: true).order(:created_at).limit(10)
• Lazy Evaluation:
  Use it when you want to build queries without executing them immediately, as where queries are executed only when accessed.

4. When We Don’t Want to Use It

• Fetching a Single Record:
  Avoid where if you only need the first matching record. Use find_by or where(...).first: User.where(active: true).first
• Complex Joins or Subqueries:
  For advanced SQL needs, consider raw SQL or Arel.
• Checking Existence:
  If you only need to check if records exist, use exists? for better performance: User.where(active: true).exists?

5. More Examples

• Retrieve Active Users: active_users = User.where(active: true)
• Filter by Multiple Conditions: active_admins = User.where(active: true, role: 'admin')
• Combine with Scopes: class User < ApplicationRecord
scope :active, -> { where(active: true) }
end
active_users = User.active
• Lazy Loading Example: query = User.where(active: true) # No database call yet users = query.to_a # Database call executed here
• Count Active Users: active_count = User.where(active: true).count

6. Questions and Answers

1. Q: What does User.where(active: true) return?
   A: It returns an ActiveRecord::Relation object containing all matching records.
2. Q: Can where handle multiple conditions?
   A: Yes, you can pass multiple key-value pairs: User.where(active: true, role: 'admin')
3. Q: Is the query executed immediately?
   A: No, where is lazily evaluated and executed only when data is accessed.
4. Q: What happens if no records match?
   A: It returns an empty ActiveRecord::Relation.
5. Q: Can we combine where with associations?
   A: Yes, it works seamlessly with associations: Post.joins(:user).where(users: { active: true })

7. Case Study

Scenario:
An e-commerce platform used User.where(active: true) to fetch active users for email notifications. As the user base grew, performance issues emerged due to large datasets and inefficient queries.

Challenges:

1. Query returned thousands of active users, leading to high memory usage.
2. Chaining with includes(:orders) caused N+1 query issues.

Solution:

1. Implemented pagination to limit the number of records fetched: User.where(active: true).limit(100)
2. Added eager loading to reduce N+1 queries: User.where(active: true).includes(:orders)
3. Indexed the active column for faster lookups: add_index :users, :active

Results:

• Reduced memory usage and query time.
• Efficient handling of large datasets.

8. Alternative

• Using Scopes:
  Define a reusable scope for active users: scope :active, -> { where(active: true) } User.active
• Using find_each for Large Datasets:
  Process active users in batches: User.where(active: true).find_each do |user| # Process each user end
• Using exists? for Boolean Checks:
  To check if active users exist: User.where(active: true).exists?
• Using Custom SQL for Complex Queries:
  For more advanced needs:rubyCopy codeUser.where("active = ? AND created_at > ?", true, 1.year.ago)

9. How to Optimize It

1. Index the Filtered Column:
   Add an index to the active column to speed up queries: add_index :users, :active
2. Use select to Fetch Specific Columns:
   Avoid fetching unnecessary data: User.where(active: true).select(:id, :name)
3. Paginate Results:
   Use gems like kaminari or will_paginate to handle large datasets: User.where(active: true).page(params[:page]).per(20)
4. Avoid N+1 Queries:
   Use eager loading for associations: User.where(active: true).includes(:posts)
5. Batch Processing:
   Process large datasets in batches to reduce memory usage: User.where(active: true).find_in_batches(batch_size: 100) do |group| # Process each group end

10. Case Study (Summarized)

Scenario:
An online service used User.where(active: true) to fetch active users for promotional emails. The query performed well initially but slowed down as the user base grew.

Solution:

1. Indexed the active column for faster lookups.
2. Used pagination to limit results for each query.
3. Optimized queries by fetching only required fields with select.
4. Eager loaded related data to avoid N+1 issues.

Outcome:

Enhanced scalability for handling larger datasets.

Improved query performance by 70%.

Reduced memory usage and database load.

Active Record in Rails simplifies data retrieval with efficient methods like pluck. The query User.pluck(:name) is commonly used to retrieve specific columns directly from the database. Let’s explore its details, use cases, and best practices.

1. Detail

User.pluck(:name) retrieves the name column values from all records in the users table and returns them as an array.
It avoids loading full Active Record objects, making it faster and memory-efficient for such use cases.

2. Equivalent to Raw SQL Query

The query translates to:

SELECT "users"."name" FROM "users";

This fetches only the name column from the users table, avoiding other unnecessary data.

3. When and Where We Use It

• Retrieving Specific Columns:
  Use pluck when you need only specific attributes, such as name or email, without instantiating full Active Record objects.
• Improving Performance:
  It is much faster and uses less memory compared to methods like map or select, which load entire objects into memory.
• Simple Data Manipulation:
  Useful for scenarios like generating dropdown options, creating simple lists, or performing calculations on a single column: User.pluck(:name)

4. When We Don’t Want to Use It

• When Full Records Are Needed:
  Avoid pluck if you need to work with complete Active Record objects and their associations: users = User.where(active: true) # Better for objects
• Complex Data Transformations:
  Use other methods when additional processing or transformations are required.
• Fetching Large Datasets for Real-Time Usage:
  For large datasets, consider pagination or batch processing instead of retrieving all values at once.

5. More Examples

• Retrieve a Single Column: names = User.pluck(:name)
• Retrieve Multiple Columns: names_and_emails = User.pluck(:name, :email)
• Combine with where: active_names = User.where(active: true).pluck(:name)
• Distinct Values: distinct_names = User.distinct.pluck(:name)
• Sorting Results: sorted_names = User.order(:name).pluck(:name)

6. Questions and Answers

1. Q: What does User.pluck(:name) return?
   A: It returns an array of name values from the users table.
2. Q: Can pluck fetch multiple columns?
   A: Yes, it can retrieve multiple columns as arrays of arrays: User.pluck(:name, :email)
3. Q: How is pluck different from map?
   A: pluck directly queries the database and retrieves only the specified columns, while map loads full Active Record objects into memory and extracts data in Ruby.
4. Q: Can we use pluck with conditions?
   A: Yes, it works seamlessly with Active Record query methods: User.where(active: true).pluck(:name)

7. Case Study

Scenario:
An admin dashboard used User.all.map(&:name) to display all user names in a dropdown. As the dataset grew, the query became slow and memory-intensive.

Challenges:

1. High memory usage due to loading full Active Record objects.
2. Performance bottleneck with a growing user base.

Solution:
Replaced map with pluck:

names = User.pluck(:name)

Results:

• Query execution time improved significantly.
• Reduced memory usage by avoiding Active Record instantiation.

8. Alternative

• Using map:
  While less efficient, map can be used if full records are needed: names = User.all.map(&:name)
• Using select with Active Record: Retrieve specific fields while keeping Active Record objects: users = User.select(:name)
• Using Custom SQL: For advanced use cases: names = ActiveRecord::Base.connection.execute("SELECT name FROM users").to_a

9. How to Optimize It

1. Index the Column:
   Ensure the column being queried (e.g., name) is indexed for faster lookups: add_index :users, :name
2. Retrieve Only Necessary Data:
   Use pluck for specific fields and avoid loading unnecessary data: User.pluck(:name)
3. Use distinct for Unique Values:
   Avoid duplicates when required: User.distinct.pluck(:name)
4. Combine with Other Queries:
   Combine with filtering methods like where or order for targeted results: User.where(active: true).order(:name).pluck(:name)

10. Case Study (Summarized)

Scenario:
An analytics tool used User.all.map(&:name) to generate a report. As the dataset grew, performance degraded due to high memory consumption.

Solution:
Replaced map with pluck to retrieve only the required column (name) directly from the database:

names = User.pluck(:name)

Outcome:

• Reduced memory usage by 80%.
• Improved query execution time, making the application more scalable.
• Achieved better database performance with indexed columns.