Showing posts with label response. Show all posts
Showing posts with label response. Show all posts

Sunday, March 25, 2012

basic design question

i am a beginner and any response will help me a lot.

i have 20 types of products,
each product has about 40 fields, most of them are common fileds for all products, but some of them are unique.

the number of the unique fields of all the product types is 75.

the question:
Should i build one products table with 75 fields and leave nulls where a field is not property of a product type?
Or should i build a products table for the 30 common fields and a 20 different tables for each product type extra fields?
Or just build 20 different tables each product type?

other ideas are welcome

you can use Named-pair design technique that is very comon in Software as Service application where we have to maintained the list of customer and some customer can have attribtues that are uncomon to other.

create a table called ProductAttributs that can have column like

1- ProductAttributeID,Attribute Name , Data Type ,IsNull

then Create another table called Product Attribute Value that has column

1-ProductID

2-ProductAttribute ID

3- Value

and you have a base table Product which contains the common fields only

so by this first you can create a set of advance product attributes in Product Attribute Table

then bind your product table with Product Advance attributes in product attribute value so by this you can manage dynamic Product attributes that are not comon in ever Product.

|||

hi., please help me, i am a student, i have basic idea on webprogramming specially ASP.NET, actually im using Visual Web Developer.,

i have a new "complicated" project. i really need help.

1st. the data base, this is the diagram of the data, it is not the actual form but its more like this:

diagram

if i will do it in the form of access, it will look like this.

LinkFromLinkToexisting1depleted1fots_brae1cdma_fots1 1111AngelesArayat16800AngelesBalanga27000AngelesBalibago63000AngelesClark16000AngelesDinalupihan0000AngelesHermosa0000AngelesMacabebe64000AngelesMagalang16800AngelesOrani0000AngelesSFP7312600AntipoloAntipolo RSU16000AntipoloTanay42000BacoorBacoor RSU166300BacoorCavite City16000BacoorDasmarinas152100BacoorImus63000BacoorKawit16000BaguioBaguio RLU/ELU1111BaguioLa Trinidad1111BalagtasAngat1111BalagtasAngeles1111BalagtasBocaue1111BalagtasCabanatuan1111BalagtasGuiguinto1111BalagtasIba1111BalagtasMalolos1111BalagtasMarilao1111BalagtasMeycauayan1111BalagtasNorzagaray1111BalagtasPandi1111BalagtasSan Jose DM1111BalagtasSta. Maria1111BalagtasTarlac1111BatangasLemery1111BatangasLipa1111BatangasMamburao1111BatangasSan Jose1111BatangasSto. Tomas1111BinalonanAsingan1111BinalonanBaguio1111BinalonanBalagtas1111BinalonanBalungao1111BinalonanDagupan1111BinalonanLaoag1111BinalonanLingayen1111BinalonanMt. Kabuyao RS1111BinalonanPozzorubio1111BinalonanRosales1111BinalonanSan Carlos1111BinalonanSan Isidro RS1111BinalonanSan Manuel1111BinalonanSan Nicolas1111BinalonanSan Quintin1111BinalonanSantiago1111BinalonanSFU1111BinalonanSison1111BinalonanSta. Maria1111BinalonanTayug1111BinalonanTuguegarao1111BinalonanUmingan1111BinalonanUrdaneta1111BinalonanVigan1111BinalonanVillasis1111

if you would look on the table and the diagram, there are just 2 lavel in the table which is in the diagram has 3 level.

thisis the story about that. the table also has 3 level, look on the Boldwords, if you would look on the many "angeles" there is also not so farbeneath a single "angles" but this time, he is under "balagtas", sothis is the levels, "Balagtas --> Angeles--> (bold names underangeles)" how to know the other names with same levels,

@. lookfor names that are inputed in many times in the "LinkFrom" header thenlook for the same name in the "LinkTo" header. so just look closely inthe table so you can under stand the format.

so this is the question, how can i design my database from access?? what will it look like?

after the database, this is the story for how should the web page operate.

@. assumption: that there will be 3 dropdown menu, each menu correspond to each level.

sofor example, if i choose an item in the level 3 dropdown menu, it willshow a table or info (if you would look in the table above, it will bethe numbers' "1's") for:

1. link from level 2 to level 3.
2. link from level 1 to level 2

so to make it short, will should detect he's original link were ever he was link to.

so if i select a value from the level 2 dropdown, it will only show the link from level 1 to level 2

if select a value from level 3 it will show link from level 2 to level 3 and level 1 tot level 2.

it should trace were he is connected so i think the real key here is the design of the database.

actuallythe table i show to you is the real table but i cut it to make itshort. so there are still some 3 level layer out there in the sameformation as the "Balagtas --> Angeles --> under angeles" intwo columns style.


i hope someone can help me tothis,...please. this day is friday here in the philippines, i willhave no class tomorow, only here in the school were i can work and openthis forum. i hope in monday there will be an answer. thanks in advanceto any person.

please feel free to ask it you want to know any clarification to my post.

SALAMAT PO...

Tuesday, March 20, 2012

Bad sql query and slow response

Can someone please confirm with me that this is not a good sql query. It
takes so long to run. ALso, can someone please re-write it for me. Thank
you.
SELECT * FROM CASE WHERE
LTRIM(RTRIM(DLASTNAME)) like 'rumfield%'
AND LTRIM(RTRIM(DFIRSTNAME)) like 'nunu%' order by C_codes
"James Juno" <JamesJuno@.discussions.microsoft.com> wrote in message
news:8D4AC99A-1578-4BE3-8F87-F44A09D4F9D4@.microsoft.com...
> Can someone please confirm with me that this is not a good sql query. It
> takes so long to run. ALso, can someone please re-write it for me. Thank
> you.
> SELECT * FROM CASE WHERE
> LTRIM(RTRIM(DLASTNAME)) like 'rumfield%'
> AND LTRIM(RTRIM(DFIRSTNAME)) like 'nunu%' order by C_codes
If you can guarantee that DLASTNAME and DFIRSTNAME are never stored with
leading ' '.
Then
SELECT * FROM CASE WHERE
DLASTNAME like 'rumfield%'
and DFIRSTNAME like 'nunu%'
order by C_codes
Would be faster, and could use an index on DLASTNAME or DFIRSTNAME.
David
|||Make sure you pre-process the column data and remove any spaces before you
hit the query. Putting functions on columns like that forces SQL Server to
table scan, making index usage impossible. And make sure you have a
composite index on lastname + firstname.
And never, never, never, ever use SELECT * in a production query.
David Gugick
Imceda Software
"James Juno" <JamesJuno@.discussions.microsoft.com> wrote in message
news:8D4AC99A-1578-4BE3-8F87-F44A09D4F9D4@.microsoft.com...
> Can someone please confirm with me that this is not a good sql query. It
> takes so long to run. ALso, can someone please re-write it for me. Thank
> you.
> SELECT * FROM CASE WHERE
> LTRIM(RTRIM(DLASTNAME)) like 'rumfield%'
> AND LTRIM(RTRIM(DFIRSTNAME)) like 'nunu%' order by C_codes
|||Not to mention that [CASE] is a HORRID table name given that it is a SQL
Server RESERVED WORD.
Also consider an index for C_codes. You should consider an Index for the
names even if you don't trim them. Why would they have leading spaces in the
names?
Sincerely,
Anthony Thomas
"James Juno" wrote:

> Can someone please confirm with me that this is not a good sql query. It
> takes so long to run. ALso, can someone please re-write it for me. Thank
> you.
> SELECT * FROM CASE WHERE
> LTRIM(RTRIM(DLASTNAME)) like 'rumfield%'
> AND LTRIM(RTRIM(DFIRSTNAME)) like 'nunu%' order by C_codes
|||James,
Defining 'good' is somewhat difficult without any context but the following
may help:
Any use of a function against a column used in the where clause is likely to
result in a table scan. In your case the LTRIM(RTRIM bit is prety well
certain to result an scan as it is impossible to use an index to support it.
(You 'may' get away with RTRIM on it's own using an index, but would need to
check. But then how big is the table? If only small who cares if scan is
needed, however if it contains a lreg number of rows you will care a great
deal.
What datatype is the column - if varchar then Rtrim is probably not needed
anyway.
Avoid the Ltrim in the where clause and Ltrim stuff on input if needs be.
Look at the indexes on Dlastname and Dfirstname
Finaly if these are real names does "case" mean something sensible, and
similarly what does the D signify - but we could be opening a whole new
discussion!
Mike John
"James Juno" <JamesJuno@.discussions.microsoft.com> wrote in message
news:8D4AC99A-1578-4BE3-8F87-F44A09D4F9D4@.microsoft.com...
> Can someone please confirm with me that this is not a good sql query. It
> takes so long to run. ALso, can someone please re-write it for me. Thank
> you.
> SELECT * FROM CASE WHERE
> LTRIM(RTRIM(DLASTNAME)) like 'rumfield%'
> AND LTRIM(RTRIM(DFIRSTNAME)) like 'nunu%' order by C_codes
sql

Bad sql query and slow response

Can someone please confirm with me that this is not a good sql query. It
takes so long to run. ALso, can someone please re-write it for me. Thank
you.
SELECT * FROM CASE WHERE
LTRIM(RTRIM(DLASTNAME)) like 'rumfield%'
AND LTRIM(RTRIM(DFIRSTNAME)) like 'nunu%' order by C_codes"James Juno" <JamesJuno@.discussions.microsoft.com> wrote in message
news:8D4AC99A-1578-4BE3-8F87-F44A09D4F9D4@.microsoft.com...
> Can someone please confirm with me that this is not a good sql query. It
> takes so long to run. ALso, can someone please re-write it for me. Thank
> you.
> SELECT * FROM CASE WHERE
> LTRIM(RTRIM(DLASTNAME)) like 'rumfield%'
> AND LTRIM(RTRIM(DFIRSTNAME)) like 'nunu%' order by C_codes
If you can guarantee that DLASTNAME and DFIRSTNAME are never stored with
leading ' '.
Then
SELECT * FROM CASE WHERE
DLASTNAME like 'rumfield%'
and DFIRSTNAME like 'nunu%'
order by C_codes
Would be faster, and could use an index on DLASTNAME or DFIRSTNAME.
David|||Make sure you pre-process the column data and remove any spaces before you
hit the query. Putting functions on columns like that forces SQL Server to
table scan, making index usage impossible. And make sure you have a
composite index on lastname + firstname.
And never, never, never, ever use SELECT * in a production query.
David Gugick
Imceda Software
"James Juno" <JamesJuno@.discussions.microsoft.com> wrote in message
news:8D4AC99A-1578-4BE3-8F87-F44A09D4F9D4@.microsoft.com...
> Can someone please confirm with me that this is not a good sql query. It
> takes so long to run. ALso, can someone please re-write it for me. Thank
> you.
> SELECT * FROM CASE WHERE
> LTRIM(RTRIM(DLASTNAME)) like 'rumfield%'
> AND LTRIM(RTRIM(DFIRSTNAME)) like 'nunu%' order by C_codes|||Not to mention that [CASE] is a HORRID table name given that it is a SQL
Server RESERVED WORD.
Also consider an index for C_codes. You should consider an Index for the
names even if you don't trim them. Why would they have leading spaces in th
e
names?
Sincerely,
Anthony Thomas
"James Juno" wrote:

> Can someone please confirm with me that this is not a good sql query. It
> takes so long to run. ALso, can someone please re-write it for me. Thank
> you.
> SELECT * FROM CASE WHERE
> LTRIM(RTRIM(DLASTNAME)) like 'rumfield%'
> AND LTRIM(RTRIM(DFIRSTNAME)) like 'nunu%' order by C_codes|||James,
Defining 'good' is somewhat difficult without any context but the following
may help:
Any use of a function against a column used in the where clause is likely to
result in a table scan. In your case the LTRIM(RTRIM bit is prety well
certain to result an scan as it is impossible to use an index to support it.
(You 'may' get away with RTRIM on it's own using an index, but would need to
check. But then how big is the table? If only small who cares if scan is
needed, however if it contains a lreg number of rows you will care a great
deal.
What datatype is the column - if varchar then Rtrim is probably not needed
anyway.
Avoid the Ltrim in the where clause and Ltrim stuff on input if needs be.
Look at the indexes on Dlastname and Dfirstname
Finaly if these are real names does "case" mean something sensible, and
similarly what does the D signify - but we could be opening a whole new
discussion!
Mike John
"James Juno" <JamesJuno@.discussions.microsoft.com> wrote in message
news:8D4AC99A-1578-4BE3-8F87-F44A09D4F9D4@.microsoft.com...
> Can someone please confirm with me that this is not a good sql query. It
> takes so long to run. ALso, can someone please re-write it for me. Thank
> you.
> SELECT * FROM CASE WHERE
> LTRIM(RTRIM(DLASTNAME)) like 'rumfield%'
> AND LTRIM(RTRIM(DFIRSTNAME)) like 'nunu%' order by C_codes

Bad sql query and slow response

Can someone please confirm with me that this is not a good sql query. It
takes so long to run. ALso, can someone please re-write it for me. Thank
you.
SELECT * FROM CASE WHERE
LTRIM(RTRIM(DLASTNAME)) like 'rumfield%'
AND LTRIM(RTRIM(DFIRSTNAME)) like 'nunu%' order by C_codes"James Juno" <JamesJuno@.discussions.microsoft.com> wrote in message
news:8D4AC99A-1578-4BE3-8F87-F44A09D4F9D4@.microsoft.com...
> Can someone please confirm with me that this is not a good sql query. It
> takes so long to run. ALso, can someone please re-write it for me. Thank
> you.
> SELECT * FROM CASE WHERE
> LTRIM(RTRIM(DLASTNAME)) like 'rumfield%'
> AND LTRIM(RTRIM(DFIRSTNAME)) like 'nunu%' order by C_codes
If you can guarantee that DLASTNAME and DFIRSTNAME are never stored with
leading ' '.
Then
SELECT * FROM CASE WHERE
DLASTNAME like 'rumfield%'
and DFIRSTNAME like 'nunu%'
order by C_codes
Would be faster, and could use an index on DLASTNAME or DFIRSTNAME.
David|||Make sure you pre-process the column data and remove any spaces before you
hit the query. Putting functions on columns like that forces SQL Server to
table scan, making index usage impossible. And make sure you have a
composite index on lastname + firstname.
And never, never, never, ever use SELECT * in a production query.
--
David Gugick
Imceda Software
"James Juno" <JamesJuno@.discussions.microsoft.com> wrote in message
news:8D4AC99A-1578-4BE3-8F87-F44A09D4F9D4@.microsoft.com...
> Can someone please confirm with me that this is not a good sql query. It
> takes so long to run. ALso, can someone please re-write it for me. Thank
> you.
> SELECT * FROM CASE WHERE
> LTRIM(RTRIM(DLASTNAME)) like 'rumfield%'
> AND LTRIM(RTRIM(DFIRSTNAME)) like 'nunu%' order by C_codes|||Not to mention that [CASE] is a HORRID table name given that it is a SQL
Server RESERVED WORD.
Also consider an index for C_codes. You should consider an Index for the
names even if you don't trim them. Why would they have leading spaces in the
names?
Sincerely,
Anthony Thomas
"James Juno" wrote:
> Can someone please confirm with me that this is not a good sql query. It
> takes so long to run. ALso, can someone please re-write it for me. Thank
> you.
> SELECT * FROM CASE WHERE
> LTRIM(RTRIM(DLASTNAME)) like 'rumfield%'
> AND LTRIM(RTRIM(DFIRSTNAME)) like 'nunu%' order by C_codes|||James,
Defining 'good' is somewhat difficult without any context but the following
may help:
Any use of a function against a column used in the where clause is likely to
result in a table scan. In your case the LTRIM(RTRIM bit is prety well
certain to result an scan as it is impossible to use an index to support it.
(You 'may' get away with RTRIM on it's own using an index, but would need to
check. But then how big is the table? If only small who cares if scan is
needed, however if it contains a lreg number of rows you will care a great
deal.
What datatype is the column - if varchar then Rtrim is probably not needed
anyway.
Avoid the Ltrim in the where clause and Ltrim stuff on input if needs be.
Look at the indexes on Dlastname and Dfirstname
Finaly if these are real names does "case" mean something sensible, and
similarly what does the D signify - but we could be opening a whole new
discussion!
Mike John
"James Juno" <JamesJuno@.discussions.microsoft.com> wrote in message
news:8D4AC99A-1578-4BE3-8F87-F44A09D4F9D4@.microsoft.com...
> Can someone please confirm with me that this is not a good sql query. It
> takes so long to run. ALso, can someone please re-write it for me. Thank
> you.
> SELECT * FROM CASE WHERE
> LTRIM(RTRIM(DLASTNAME)) like 'rumfield%'
> AND LTRIM(RTRIM(DFIRSTNAME)) like 'nunu%' order by C_codes

Monday, March 19, 2012

bad querry - with very slow response

Can someone please tell me why this code is returning results after too much
time and can you please tell me how I can fix it? Thank you for your help.
SELECT * FROM CASE WHERE
LTRIM(RTRIM(DLASTNAME)) like 'rumfield%'
AND LTRIM(RTRIM(FIRSTNAME)) like 'nunu%' order by C_codes
James
asked and answered...

bad querry - with very slow response

Can someone please tell me why this code is returning results after too much
time and can you please tell me how I can fix it? Thank you for your help.
SELECT * FROM CASE WHERE
LTRIM(RTRIM(DLASTNAME)) like 'rumfield%'
AND LTRIM(RTRIM(FIRSTNAME)) like 'nunu%' order by C_codes
Jamesasked and answered...

bad querry - with very slow response

Can someone please tell me why this code is returning results after too much
time and can you please tell me how I can fix it? Thank you for your help.
SELECT * FROM CASE WHERE
LTRIM(RTRIM(DLASTNAME)) like 'rumfield%'
AND LTRIM(RTRIM(FIRSTNAME)) like 'nunu%' order by C_codes
Jamesasked and answered...