How to create MySQL view that ignores WHERE conditions and returns fixed data

Other Questions MySQL
1

I need to set up a MySQL table or view that will always return the same dataset no matter what WHERE clause is used in the query.

For example, when I run:

select * from products where category_id = 100

I want it to show:

item_id  title        details
10       engine       powerful motor unit  
20       brake        stops the vehicle
30       tire         rubber wheel cover

And when I execute:

select * from products where category_id = 999

I need the exact same results returned.

I cannot change the application code that runs these queries, so I’m looking for a database-level solution. Is there some way to create a view or use some other MySQL feature that will basically ignore any WHERE conditions and always return my predetermined result set?

2

This reminds me of debugging a vendor integration where the app kept sending hardcoded WHERE clauses we couldn’t touch. Here’s what I learned: MySQL views will try to execute WHERE conditions against whatever columns exist in the view definition.

I found a reliable workaround - create a view that deliberately leaves out the problematic filter columns:

CREATE VIEW products AS
SELECT 10 as item_id, 'engine' as title, 'powerful motor unit' as details
UNION ALL
SELECT 20, 'brake', 'stops the vehicle'
UNION ALL
SELECT 30, 'tire', 'rubber wheel cover'

Since there’s no category_id column in this view, MySQL can’t apply the WHERE category_id condition and returns all rows. I’ve used this in production where we couldn’t modify the application queries.

Just make sure your static data matches the expected column types and names exactly, or you’ll get weird casting issues or application errors.

3

Yeah, this is pretty common when you’re stuck serving static data but can’t touch the application layer. I’ve hit this with legacy systems that expect dynamic queries but need the same results every time.

Here’s a view using subqueries:

CREATE VIEW products AS
SELECT * FROM (
  SELECT 10 as item_id, 'engine' as title, 'powerful motor unit' as details
  UNION ALL
  SELECT 20, 'brake', 'stops the vehicle'
  UNION ALL  
  SELECT 30, 'tire', 'rubber wheel cover'
) AS fixed_data

This view returns your fixed dataset no matter what WHERE conditions get thrown at it - the subquery spits out the same static rows every time.

But honestly? Database workarounds like this get messy fast. What happens when you need different static datasets for different conditions? Or when things get more complex?

I’ve had way better luck intercepting these queries at the application layer with automation. You can set up Latenode to catch database requests, apply custom logic, and return exactly what you need without hacking your database schema.

Latenode lets you build workflows that monitor database calls and return predetermined responses based on your rules. Way cleaner than view tricks and easier to maintain.

4

i had the same probelm with a terrible cms that kept hammers our db. try switching from a view to a regular table - it works better with older mysql versions. just run CREATE TABLE products (item_id int, title varchar(50), details text) and insert your static data. the where clauses will still execute but without a matching category_id column, it’ll return all rows anyway.

5

Been there with legacy apps that spam queries you can’t control. Views work, but they get brittle at scale.

Everyone’s missing the obvious solution - database middleware. Instead of hacking views or tables, just intercept those queries before they hit your database.

I had a vendor tool hammering our production MySQL with random WHERE clauses. Views worked at first, but became a nightmare when we needed different static responses for different query patterns.

Game changer was query interception with automation. Catch those SELECT statements, parse what they want, and return your predetermined datasets without touching the database structure.

Latenode handles this perfectly - build workflows that monitor incoming database requests and respond with exactly the data you want. No view maintenance, no casting issues, and you can easily adjust responses for different patterns without schema changes.

Way more flexible than hardcoding static data in views, especially when requirements change.

6

I hit this exact problem a few years back with a third-party reporting tool I couldn’t modify. UNION works, but there’s a cleaner way using VALUES:

CREATE VIEW products AS
SELECT * FROM (VALUES 
    ROW(10, 'engine', 'powerful motor unit'),
    ROW(20, 'brake', 'stops the vehicle'),
    ROW(30, 'tire', 'rubber wheel cover')
) AS t(item_id, title, details)

Here’s what happens: MySQL views ignore WHERE conditions for columns that aren’t in the view’s logic. Your static data doesn’t use category_id or other filter columns, so those WHERE clauses do nothing.

Watch out for data types though. I got burned initially because the app expected specific varchar lengths and numeric types. You might need to cast your values if you hit type mismatches.