Joel Brown

@R..GitHubSTOPHELPINGICE We bought at the market price, actually a little less because the house was a company move sale, so the owner was guaranteed a price regardless of what his employer decided to let it go for. It's just that the market was over-heated. We bought knowing that it was overheated, but the conventional wisdom at the time was "get in now or you'll never be able to afford to get in". We discovered that what goes up can certainly come back down, at least for a while.

Definitely this. The first house my wife and I bought after we were married cost $167K. We sold it 7 years later for $125K - $5K less than we still owed on it, and all of that after pouring many thousands of dollars and countless hours of sweat equity into improving the place. If we had rented for the first 7 years of our married life we would have had $5K more equity and who knows how many more (tens of) thousands of additional savings. What's more, we had to commute 45 miles further to work than we might have if we had rented, because that's where our affordability limit was.

Semantically there is a huge difference between Null (don't know) and Null (don't care). Not making a distinction between these in either the standard or the various implementations makes for a lot of resulting confusion. You could say that all "null/don't know" are equal but all "null/don't care" are distinct, for example. It makes for strange, arbitrary implementation decisions by each RDBMS builder.

On Windows it would probably display as [poop-emoji]WATCH. At least that's how I'd set the U+F8FF private-use character code in Windows if I worked at Microsoft.

Goodbye.

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.

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

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.

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.

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.

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"?

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.

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

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

But with EAV you would write:

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

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:

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).

That is why EAV is good for product catalogs.

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

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

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

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

My pleasure.

Hello.