September 20, 2006 at 9:03 am
ok, i have a bit of a tricky problem that I am trying to avoid using stored procedure for..but I am rapidly approching my wits end with T-Sql.
Here is a script
CREATE TABLE [dbo].[KeyWordTest] (
[ID] uniqueidentifier DEFAULT newid(),
[AccessField] nvarchar(128))
INSERT INTO KeyWordTest (AccessField) VALUES ('Appels, Oranges')
INSERT INTO KeyWordTest (AccessField) VALUES ('')
INSERT INTO KeyWordTest (AccessField) VALUES ('Appels, Oranges, Bananas')
END
September 20, 2006 at 9:11 am
First thought is - don't do it like that.
Why do you have 'apples, oranges, bananas' as a single string in a single column?
This is where your problem lies. Would it be possible to instead store each fruit as it's own row? Try it and see if you can get your query to work.
If this for some reason isn't the way to go, then from what I can read from your query, is that you need relational division.
The onecolumn-string-of-fruits, however, will make every attempt to manipulate the data a kludge, at it's best. (ie pre-work like split functions etc..)
/Kenneth
September 20, 2006 at 9:25 am
No unfortunatly i have to keep them in one row. like i described in my query. I am not sure what you meant by relational diviosn..but i look forwrd to more posts on this matter.
Sameer
September 20, 2006 at 10:56 am
Can you keep them in different columns? You are breaking the basic rule of Relational database Normalization(Normal Form  by have multi value column.
Thanks
Sreejith
September 20, 2006 at 11:19 am
I understand that..but DOD requirements dictate this type of storage.
September 20, 2006 at 11:32 am
May be you can create a temp table @keywords with an id column and an accessfield column. Split the comma seperated accessfield string from the keywordtest table and insert one row for each value. Then perform the search on this temp table. May not be efficient if you have too many rows in the keywordtest table.
September 20, 2006 at 7:04 pm
DOD eh? Haven't they heard of ISO standards for data? Sheesh! Where's Joe Celko when you need a good rant from him? He'd have a bloody fit.
Here's the "brute force" method...
SELECT *
FROM dbo.KeyWordTest
WHERE AccessField LIKE '%Apples%'
AND AccessField LIKE '%Oranges%'
AND AccessField NOT LIKE '%Bananas%'
SELECT *
FROM dbo.KeyWordTest
WHERE AccessField LIKE '%Apples%'
AND AccessField LIKE '%Oranges%'
AND AccessField LIKE '%Bananas%'
Now... in order to come up with something a bit more sophisticated, we probably need to know how many different items the AccessField can contain... any thoughts there, Sameer?
--Jeff Moden
Change is inevitable... Change for the better is not.
September 21, 2006 at 1:23 am
What's DOD? The only thing that comes into my mind is Dead On Delivery... which somehow seems to be appropriate as I read what you are asked to do. We'll try to come up with something, but most probably it will not perform well if you have many rows in this table.
September 21, 2006 at 7:08 am
DOD > Dead on Dear Vladan .
September 21, 2006 at 7:12 am
DOD = Department of Defense. It sets standards just like ISO etc..
September 21, 2006 at 7:19 am
So they think they overthrow data modeling standards???
I wouldn't like to be in your position right now... I hope this is the only sample of this problem you'll find !!
September 21, 2006 at 9:01 am
That's why I was going on about the ISO standards... they were supposed to be a key in developing the ISO standards for SQL and Data. Guess they forgot everything they knew when Celko left the ISO committee
--Jeff Moden
Change is inevitable... Change for the better is not.
September 21, 2006 at 9:04 am
Sameer,
You all set with the brute force method I gave you or do you need something more sophisticated? If the latter, I need some more details to help...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 21, 2006 at 9:10 am
Yes indeed I am all set with the brute force method. Actually more like a stored proc. While I work on implementing or perhaps reinventing the data rules within standards of course.
September 21, 2006 at 9:50 am
Thanks Rémi 🙂
That Ninja part is a new addition, isn't it? I didn't see your posts for a while though, so it may be some time since you've renamed yourself.
Oh, Department of Defense. Well, then it isn't too surprising. In my country, they buy parachutes that don't always open, fire guns in an airplane by mistake etc. No wonder they don't know how to design a DB.
Viewing 15 posts - 1 through 15 (of 18 total)
You must be logged in to reply to this topic. Login to reply