hi

Hello.

first of all thanks for your time.....

i am newbie , dont know anything about quesries

My pleasure.

we are doing site like this : stackoverflow.com/questions/39634638/…

ecommerce

so is it too much difficult to write queries for eav tables ?

as so many said eav is difficult , i posted this question : dba.stackexchange.com/questions/150381/…

The place to use EAV in an ecommerce application is for product features.

okay than we have to use eav only for "e-commerece products - attributes "

In a product catalog, the features don't mean anything. They are only there to make a list like this: "feature name": "feature value".

You might make a list of these or maybe a comparison grid for products as columns and features as rows.

Don't use EAV for things about customers, or orders or anything else. For product features EAV is a reasonable design choice.

client is not in position to finalize all products and product types and the attributes

That is why EAV is good for product catalogs.

please check above image, you are telling use `eav only for "category, products , attributes" ?

for others i need to use flat tables right ?

There are always new products with different types of features. EAV lets you define this as data. This is what makes EAV good for product attributes. For everything else you should start with tables in Third Normal Form (3NF).

fine, is it too much difficult to write queries for eav tables ?

No, the opposite is true for product catalog queries. For example if you didn't use EAV and you wanted to get a list of products that were colour="Blue" you might have to write something like this:

select * from TSHIRTS where COLOUR='BLUE' UNION ALL select * from PANTS where COLOUR='BLUE' union all ... (and so forth for every type of product)

But with EAV you would write:

than writing queries for "online product catalog" is much easier if we use eav compare to flat tables

also i saw your comment here :

select * from PRODUCTS P inner join ATTRIBUTES A on P.id = A.product_id where A.value = 'Blue'

@PhpBeginner Why do you say that performance problems are inevitable using EAV for a product catalog? I don't think that is a fair comment. Please be specific about what will perform worse? This kind of generalization is precisely what I'm talking about in this answer. EAV is evil for most applications. Online product catalogs is not one of them. In this specific scenario you cannot say

"EAV is slow", or "EAV makes your queries complicated", or "EAV removes meaning from the data" or any of the other things that are usually valid criticisms of EAV

That is all, and it doesn't matter if you add more types of products.

oh thats great for newbie like me as i dont have much knowledge in writing quesries

now last one is performance

Everything is a design choice. There are always trade-offs. You have to understand what the trade-offs are and make the best choice for your situation.

Why do you think EAV will have performance problems? Is there some specific issue you are worried about or is it just that everyone always says "EAV is slow"?

okay with our bad quesries and design if we face performance problems in future than how to solve it.....

as i am working with magento, i felt magento sites are slow because of "eav"

also everyone saying "eav slow"

Magneto is good for what it is good for. If you use it for the wrong purpose it could be slow, or it could make it hard to enforce data integrity.

w eare using shopping sites only

okay last one , if not eav, any option for us for online catalog products ?

EAV in a relational database will be slower than flat tables, as long as you can predict in advance what columns you will be querying. EAV in a product catalog has predictable columns. Don't worry about there being more rows. Relational database systems are built to handle lots of rows easily and quickly.

fine , can you look at this : dba.stackexchange.com/questions/150381/…

If you know all of the product types and all of their features in advance, then you can use a 3NF model. But you said that the user of the system can't predict this. I'll post an answer to the question on DBA.SE.

yes we cant predict , even client said the same.....

I've posted an answer to that question. Please have a look.

sure, look like you are father of "eav"

I hope that I am the father of "use common sense" and "understand what you're doing" rather than just following rules of thumb without understanding why that rule was established. I'm afraid I have to drop off of chat now. I've got a series of meetings to get to. Good luck with your project. I'll try to comment on any other questions you might have later tonight if you have them.

thanks al ot for your valuable time......

you cleared all doubts, you can leave chat.....

Goodbye.

goosbye

goodbye