One of the problems with "dumbed down" examples is that the solutions don't necessarily apply well to the full-scale real-world problem, often due to surprisingly simple differences that suddenly render the original solution totally worthless because the real-world scenario breaks one of the seemingly reasonable assumptions associated with the dumbed down version of the problem. Also, you didn't exactly state what kind of result you were looking for - just that you were looking for cursor alternatives. That's kind of like asking for alternatives to a perfectly good band-aid. A cursor is not necessarily evil, but given that we don't even know what kind of cursor code you're looking at, I don't see how anyone could possibly give you any useful advice. As we don't have either a statement of the problem or the alleged evil cursor to look at, we've nothing to go on. As many others have stated, help us help you...
TheGreenShepherd (7/8/2014)
I have a couple of tables that look like this:
CREATE TABLE Colors
(
Id INT NOT NULL,
ColorName VARCHAR(25)
)
CREATE TABLE Cars
(
ID INT NOT NULL,
ColorId INT NOT NULL, --FK TO Colors
CarName VARCHAR(25)
)
CREATE TABLE CarSearch
(
ID INT NOT NULL,
SearchName VARCHAR(25)
)
CREATE TABLE CarSearchCriteria
(
ID INT NOT NULL,
CarSearchId INT NOT NULL, --FK to CarSearch
ColorId INT NOT NULL, --FK to Colors
CarId INT NULL --FK to Cars
)
CarSearch contains records for searches to be performed on the Cars and Colors tables, using CarSearchCriteria to contain the search criteria.
Rules -
* A search may have more than one set of search criteria, but the final result set must be the unioned set from all criteria.
* At the very least, ColorId must be provided for CarSearchCriteria.
* If CarId is not provided for CarSearchCriteria, it should be assumed to search for all cars with that associated ColorId.
(This is just a dumbed-down analog to my actual tables, so don't question the business sense of this, please)
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)