Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Re^4: In base 1, the number after 0 is:

by tobyink (Abbot)
on May 06, 2014 at 14:08 UTC ( #1085187=note: print w/ replies, xml ) Need Help??


in reply to Re^3: In base 1, the number after 0 is:
in thread In base 1, the number after 0 is:

If you want to search for entities which contain a "Foo" part then you need to do:

SELECT entity_id FROM entities WHERE part1='Foo' OR part2='Foo' OR part3='Foo' ... OR part12='Foo';

Or perhaps slightly more concise:

SELECT entity_id FROM entities WHERE 'Foo' IN (part1, part2, part3, ..., part12);

I'd much prefer something like:

SELECT e.entity_id FROM entities e INNER JOIN entity_parts ep ON e.entity_id=ep.entity_id WHERE ep.part='Foo'

When you get to searching for different combinations of parts, the advantages of joining become even more apparent:

SELECT e.entity_id FROM entities e INNER JOIN entity_parts ep1 ON e.entity_id=ep1.entity_id INNER JOIN entity_parts ep2 ON e.entity_id=ep2.entity_id WHERE ep1.part='Foo' AND ep2.part IN ('Bar', 'Baz')

And in terms of the e-mail example, it's much easier to, say, enforce a UNIQUE constraint over a single column.

use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name


Comment on Re^4: In base 1, the number after 0 is:
Select or Download Code
Re^5: In base 1, the number after 0 is:
by chacham (Priest) on May 06, 2014 at 14:49 UTC

    When you get to searching for different combinations of parts, the advantages of joining become even more apparent

    Problem is, that is much less efficient query. EAVs are relatively terrible on performance, requiring index/table scans aplenty, unless the RDBMS supports partitioning, which effectively turns it into a bunch of small tables.

    And in terms of the e-mail example, it's much easier to, say, enforce a UNIQUE constraint over a single column.

    Yes, that is simpler. But, per the example, why enforce uniqueness on primary and secondary addresses? That would preclude the use of a friend or relative as a backup.

    Because they are attributes of a particular entity, they should each have their own column. Making two things like that unique, is not an intrinsic data rule, it is some form of business rule. A business rule should not redesign the data model to make it easier to enforce, that will only lead to problems upon problems later on. In this particular case, the rule can be enforced via a MATERIALIZED or INDEXED VIEW with a UNIQUE INDEX. (A TRIGGER could be used, but that'd be hiding code and, likely, terribly inefficient.)

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1085187]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (14)
As of 2014-11-26 15:27 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My preferred Perl binaries come from:














    Results (171 votes), past polls