No, you cannot submit an array to the LIKE operator. It is more tedious than that. :-)
When your data are not yet properly regularized, so that you have variants of the manufacturer name in the PRODUCTS table (e.g. "HP", "Hewlett Packard") rather than an integer ManufacturerID, you have to go through the grunt work of reducing those variants to a single entity.
A typical approach for doing that (quite unavoidable) work is to create a Manufacturers table like this:
Table: MANUFACTURER
manufacturerid INTEGER primary key
manufacturername varchar
primarymanufacturerid INTEGER FOREIGN KEY REFERENCES MANUFACTURER(manufacturerid)
The last column allows you to associate a variant name (e.g. "HP") with the row where the main manufacturer record is stored (e.g. "Hewlett Packard").
124, Hewlett Packard, 124
367, HP, 124
The row where primarymanufacturerid = manufacturerid is the the main entity.
Then you could do this during an interim cleanup phase when you have not yet added a manufacturerid to the PRODUCTS table but it still has the name:
select * from products
where manufacturer in
(
select manufacturername from manufacturer
where primarymanufacturerid =
(
select primarymanufacturerid from manufacturer
where manufacturername = 'Hewlett Packard'
)
)
P.S. With a database engine that had support for functions and stored procedures, you could write your own function that accepted a delimited string of name variations, built a dynamic SQL statement, possibly using a temporary table to store the variant names one name per row, and returned a count of the matches. This would be a resource-intensive approach recommended only to assist in the clean-up phase -- not something I'd put into production for end-users to consume as their daily bread.
P.P.S. And, of course, once you have your MANUFACTURER table properly created, with the primarymanufacturerid references completed, you could add a [manufacturerid] column to your PRODUCTS table and update it accordingly, and then dispense with all of this roundabout stuff.