Friends don't let friends use EAV



  • So we've got a web store. Who doesn't these days? And of course, we publish a list of our items to Google Products, to enhance search visibility. We publish maybe a dozen or so item properties - manufacturer part number, description, price, shipping weight, stuff like that. Nothing unusual there.

    But wait, this particular platform makes extensive (mis)use of EAV design "principles".

    Forty-three fucking table joins.



  • As a helpful note: it's a good idea to include a brief description of what EAV is. Keep in mind that many of the people reading this won't know what that means.


  • ♿ (Parody)

    @morbiuswilters said:

    As a helpful note: it's a good idea to include a brief description of what EAV is. Keep in mind that many of the people reading this won't know what that means.

    What? It's clear he's talking about Electroacupuncture According to Voll. I've heard that you really do have to push a lot of tables together to get all of the equipment set up.



  • @morbiuswilters said:

    As a helpful note: it's a good idea to include a brief description of what EAV is. Keep in mind that many of the people reading this won't know what that means.

    Entity-Attribute-Value: a database design approach typically employed by developers too lazy to allow for a dynamic structure.


  • ♿ (Parody)

    @db2 said:

    Entity-Attribute-Value: a database design approach typically employed by developers too lazy to allow for a dynamic structure.

    Is it just me, or does that seem oxymoronic?



  • @db2 said:

    @morbiuswilters said:
    As a helpful note: it's a good idea to include a brief description of what EAV is. Keep in mind that many of the people reading this won't know what that means.

    Entity-Attribute-Value: a database design approach typically employed by developers too lazy to allow for a dynamic structure.

    I'll risk looking really stupid here, but not counting join tables and foreign keys, wouldn't an entity tend to correspond to a row, an attribute to a column, a value to a value of a column?  Does  your database have columns entity, attribute, and value? 

    If so, you poor baby!



  • @db2 said:

    @morbiuswilters said:
    As a helpful note: it's a good idea to include a brief description of what EAV is. Keep in mind that many of the people reading this won't know what that means.

    Entity-Attribute-Value: a database design approach typically employed by developers too lazy to allow for a dynamic structure.

    Just for reference here, what do you mean by "dynamic structure"?



  • @morbiuswilters said:

    @db2 said:
    @morbiuswilters said:
    As a helpful note: it's a good idea to include a brief description of what EAV is. Keep in mind that many of the people reading this won't know what that means.

    Entity-Attribute-Value: a database design approach typically employed by developers too lazy to allow for a dynamic structure.

    Just for reference here, what do you mean by "dynamic structure"?

    As in, user/admin decides to add a new attribute for describing products or whatever. Maybe I want to be able to store the product weight in Newtons or something. Sane people would add a column called 'weight_n' to the products table. Insane people would insert a new row in the 'attribute' table. Yay, let's use a DBMS to build a DBMS.



  •  We've used EAV on an eshop before to alow the customer to edit the attributes of their products. It sounds good on paper but as it turns out the SQL queries to display the product attributes turned into monsters so we used database functions to make them simpler. Turns out having a crapload of MySQL functions run for each page working through products that number in the 5-digit range is not very fast. In fact I'd go as far as to say that the site runs like an amputee turtle.

    Caching helped a bit but there are some things you just can't cache. And of course getting rid of EAV is not exactly a minor change so it's here to stay. As for the awesome configurable backend the customer predictably never used it.


  • Trolleybus Mechanic

    @DOA said:

    We've used EAV on an eshop before to alow the customer to edit the attributes of their products.
     

    I've wondered-- what is a viable alternative to EAV? (Aside from adding a new column to the [b]product[/b] table each time a customer wants a new attribute).



  • @db2 said:

    @morbiuswilters said:
    @db2 said:
    @morbiuswilters said:
    As a helpful note: it's a good idea to include a brief description of what EAV is. Keep in mind that many of the people reading this won't know what that means.

    Entity-Attribute-Value: a database design approach typically employed by developers too lazy to allow for a dynamic structure.

    Just for reference here, what do you mean by "dynamic structure"?

    As in, user/admin decides to add a new attribute for describing products or whatever. Maybe I want to be able to store the product weight in Newtons or something. Sane people would add a column called 'weight_n' to the products table. Insane people would insert a new row in the 'attribute' table. Yay, let's use a DBMS to build a DBMS.

    Fair enough, but the systems I've seen that dynamically add columns tend to have their own problems (like most of the rows not needing the new column). If you gotta do it, you gotta do it, but I tend to favor having software engineers involved because, you know, that's their job.



  • @Lorne Kates said:

    @DOA said:

    We've used EAV on an eshop before to alow the customer to edit the attributes of their products.
     

    I've wondered-- what is a viable alternative to EAV? (Aside from adding a new column to the product table each time a customer wants a new attribute).

    XML



  • @Lorne Kates said:

    @DOA said:

    We've used EAV on an eshop before to alow the customer to edit the attributes of their products.
     

    I've wondered-- what is a viable alternative to EAV? (Aside from adding a new column to the product table each time a customer wants a new attribute).

    Put the base columns in one table, and the custom columns in another table (a one-to-one relationship on the base table's primary key). I've seen that work well enough. Optionally, provide a view that combines them.



  • @db2 said:

    Put the base columns in one table, and the custom columns in another table (a one-to-one relationship on the base table's primary key). I've seen that work well enough. Optionally, provide a view that combines them.

    All of the columns in a single table or table-per-column? Either way is suboptimal.



  • @db2 said:

    @Lorne Kates said:

    @DOA said:

    We've used EAV on an eshop before to alow the customer to edit the attributes of their products.
     

    I've wondered-- what is a viable alternative to EAV? (Aside from adding a new column to the product table each time a customer wants a new attribute).

    Put the base columns in one table, and the custom columns in another table (a one-to-one relationship on the base table's primary key). I've seen that work well enough. Optionally, provide a view that combines them.

    If you are heading that way, it might be interesting to have a look at column-oriented databases.



  • @morbiuswilters said:

    @db2 said:
    Put the base columns in one table, and the custom columns in another table (a one-to-one relationship on the base table's primary key). I've seen that work well enough. Optionally, provide a view that combines them.

    All of the columns in a single table or table-per-column? Either way is suboptimal.

    One table for all the custom columns associated with a single table. This way, you at least don't have to worry about the custom columns interfering with future database updates. It's still a bit of extra work, but nothing like 43 joins to get a dozen product columns.



  • @Speakerphone Dude said:

    If you are heading that way, it might be interesting to have a look at column-oriented databases.

    Why do you think a column-oriented database is going to help here?



  • @db2 said:

    One table for all the custom columns associated with a single table. This way, you at least don't have to worry about the custom columns interfering with future database updates.

    Admittedly better, but you still have the issue of unused columns. Also, unless I'm missing something, the custom columns can interfere with the base columns if you're using views (or if you're storing base and custom fields in the same hashtable in code, for example).



  • @morbiuswilters said:

    @Speakerphone Dude said:
    If you are heading that way, it might be interesting to have a look at column-oriented databases.

    Why do you think a column-oriented database is going to help here?

    When you have a dimension (in this case: Product) whose members (the products) have a variable number of properties, a column-oriented database is a good solution because of the specific workload: aggregations are likely to affect many items but on a small range of properties, not the other way around.

    This being said, I suggested to have a look, not to jump immediately at it, because it depends on the cardinality of the Product dimension. If they create lots and lots of products, the benefits will shrink quickly. If they have a relatively fixed amount of products, but they keep adding properties, then it becomes very interesting.



  • @Speakerphone Dude said:

    @morbiuswilters said:
    @Speakerphone Dude said:
    If you are heading that way, it might be interesting to have a look at column-oriented databases.

    Why do you think a column-oriented database is going to help here?

    When you have a dimension (in this case: Product) whose members (the products) have a variable number of properties, a column-oriented database is a good solution because of the specific workload: aggregations are likely to affect many items but on a small range of properties, not the other way around.

    This being said, I suggested to have a look, not to jump immediately at it, because it depends on the cardinality of the Product dimension. If they create lots and lots of products, the benefits will shrink quickly. If they have a relatively fixed amount of products, but they keep adding properties, then it becomes very interesting.

    For an OLTP workload like a web store, you're generally going to need a significant percentage of columns for just a few rows, so it wouldn't make sense here. I see what you're getting at, though.

    Oh, and for extra lulz, this particular platform knows that the design sucks, so you can enable "flat indexes", which are just cache tables that flatten the EAV mess and make it perform more in line with a normal web site.



  • @Lorne Kates said:

    I've wondered-- what is a viable alternative to EAV? (Aside from adding a new column to the product table each time a customer wants a new attribute).

    Not using a relational database to store non-relational data. Document databases, key-value databases, etc. Those were designed for this sort of situation and are not even capable of doing joins.

    Migrating an EAV system to one wouldn't be simple, but it wouldn't be incredibly difficult either, since the EAV virtually replicates all the same functionality, but in a really spread out normalized form. A document database, by comparison, stores all those attributes under a single record (aka: document) and in any nested structure you like. Need a new attribute on a single product? Just add it, most document databases are schema-less by design. Yes, you can enforce schemas if you want, plenty of solutions already exist, but it's not required by default and incredibly hard to implement effectively on something as flexible as product attributes.

    (Cue someone who's never actually used anything beyond a relational database telling me I'm wrong)



  • @Soviut said:

    (Cue someone who's never actually used anything beyond a relational database telling me I'm wrong)

    I have used non-relational databases, and you're mostly wrong. Non-relational databases are far behind RDBMS in terms of virtually every feature. I definitely wouldn't recommend it for this use case.



  • @morbiuswilters said:

    I tend to favor having software engineers involved because, you know, that's their job.

    Well, we, being on a programming forum, would say that, wouldn't we? Not that I think you're wrong, but I do think it's a point a higher-up decision maker might actually count in favor of a "dynamic structure".



  • @db2 said:

    So we've got a web store. Who doesn't these days? And of course, we publish a list of our items to Google Products, to enhance search visibility. We publish maybe a dozen or so item properties - manufacturer part number, description, price, shipping weight, stuff like that. Nothing unusual there.

    But wait, this particular platform makes extensive (mis)use of EAV design "principles".

    Forty-three fucking table joins.

    EAV is a "logical" solution to the problem, but in the real world has a huge number lot of drawbacks, as you state.

    I have been using XML data columns for my solutions since 2005. I wrote a CodeProject article on this, but got a lot of flak from DBA purists.



  • @morbiuswilters said:

    @Soviut said:
    (Cue someone who's never actually used anything beyond a relational database telling me I'm wrong)

    I have used non-relational databases, and you're mostly wrong. Non-relational databases are far behind RDBMS in terms of virtually every feature. I definitely wouldn't recommend it for this use case.

    How so? Schema-less documents can have attributes attached to them as needed. This seems ideal for a store that has all sorts of different products with different attributes.



  • @db2 said:

    Forty-three <obscenity> table joins.

    Soon that table will be large enough to put into the dining room for the next formal dinner.



  • EAV is badly abused; but I blame that on the developers who commit the crimes, rather than on the design pattern itself [remember one of the key elements to a well documented design pattern is to enumerate the conditions where it should not be applied]

    Some systems like CoTTiA [Correlation of Topology and Taxonomy in Advertisements] can benefit greatly. I just pulled some numbers from one of the larger systems (rounded): 80M advertisements, 3.7M unique measurements, 6.8G datapoints.

    Theoretically, if there was only one instance of a measurement per advertisement, this could be implemented by one big table (if any DB suppored 3.7M columns) with virtually all of the "cells" being null, but since most measurements allow for multiple instances of a measurement (1:M relationship) this is a non-starter. So the other extreme would be one table per measurement (or measurement set), but this would mean millions of tables. In this case, an EAV architecture has proven really effective.



  • @Soviut said:

    @Lorne Kates said:
    I've wondered-- what is a viable alternative to EAV? (Aside from adding a new column to the product table each time a customer wants a new attribute).

    Not using a relational database to store non-relational data. Document databases, key-value databases, etc. Those were designed for this sort of situation and are not even capable of doing joins.

    Migrating an EAV system to one wouldn't be simple, but it wouldn't be incredibly difficult either, since the EAV virtually replicates all the same functionality, but in a really spread out normalized form. A document database, by comparison, stores all those attributes under a single record (aka: document) and in any nested structure you like. Need a new attribute on a single product? Just add it, most document databases are schema-less by design. Yes, you can enforce schemas if you want, plenty of solutions already exist, but it's not required by default and incredibly hard to implement effectively on something as flexible as product attributes.

    (Cue someone who's never actually used anything beyond a relational database telling me I'm wrong)

     

     

    What do you do with the case where the majority of the data is relational (typical web shop is an OK example) but there's also a bunch of EAV data (e.g. product attributes that users can add)?  Use two separate data stores?

     



  • @toon said:

    @morbiuswilters said:
    I tend to favor having software engineers involved because, you know, that's their job.

    Well, we, being on a programming forum, would say that, wouldn't we? Not that I think you're wrong, but I do think it's a point a higher-up decision maker might actually count in favor of a "dynamic structure".

    Well, I hate programming and I hate programmers. I'm the last fellow who is going to suggest needlessly adding developers. However, there are times I feel a "dynamic" system is going to be suboptimal and that it's better to have a good team that can add features as necessary. I realize that probably wouldn't fly in this case, but the alternatives (EAV, adding a little-used column for every row (doesn't your RDBMS have a limit on number of columns in a table?), non-relational DBs) seem worse to me.



  • @Soviut said:

    How so? Schema-less documents can have attributes attached to them as needed. This seems ideal for a store that has all sorts of different products with different attributes.

    The underlying database engines aren't nearly as mature; even MySQL has something like 15 years of development behind it. In terms of ACID and failover, non-relational DBs don't match up; most don't even use redo logs so a crash can corrupt your database.

    In terms of schema-less design: sounds nice and flexible, but tends to lead to chaos. Indexing is often poor. Updates to the ad-hoc schema get to be messy; want to change an attribute from an int to a string? Either your code has to be able to read both and convert the int attributes to string attributes on-the-fly, or you have to write your own script to iterate all objects and update the attributes.

    Okay, you can use a schema: but if you're defining a schema for different types of products, then you could just as easily convert those types into tables, then join to a base table. You get the benefit of a mature RDBMS.

    I think the strongest argument for non-relational databases is if your data has no inherent structure; then a lack of schema comes in handy. However, I'd also say that if your data has no inherent structure, you haven't worked hard enough to identify and normalize things.



  • @Lorne Kates said:

    @DOA said:

    We've used EAV on an eshop before to alow the customer to edit the attributes of their products.
     

    I've wondered-- what is a viable alternative to EAV? (Aside from adding a new column to the product table each time a customer wants a new attribute).

    Often, just not trying to crowbar data that doesn't fit in a traditional RDBMS in there.

    What works depends a lot on what you want to do with it. Taking the products example above of wanting to represent weight in newtons, if you want to have that for all products, then you're probably looking at an extra column in the database. If it's just for one product (i.e. you want to be able to represent a bunch of extra shit, per product, on the fly), you might get away with something as crude as shoving the extra attributes into JSON or something similar and chucking that in an "extra_crap" column because if they're all different, you're not going to get much value from trying to make the data accessible to the database.

    IOW it's not a normal DB problem and if you try for "best solution" you'll probably be disappointed when you're only able to choose "least shitty".


  • Discourse touched me in a no-no place

    @SilentRunner said:

    @db2 said:

    Forty-three <obscenity> table joins.

    What happened to the fucking?


  • @_gaffer said:

    IOW it's not a normal DB problem and if you try for "best solution" you'll probably be disappointed when you're only able to choose "least shitty".

    Agreed it is not "normal" in the sense as being within the 50% (or even 90%) of a distribution curve, but neither is it that rare. If one is looking for a "one size fits all" solution, then I agree with your quoted statement. But "when the stars align" being able to harness the power of an RDBMS can provide some very attractive capabilities over alternate approaches. For example (and it is only an example) using Filtered indices on key attributes gives fantastic performance boosts. Combine this with Indexed Views, and one can even give the impression of "normalized tables" for the more common types of access....



  •  @db2 said:

    Yay, let's use a DBMS to build a DBMS.
      You've obviously never looked at the peoplesoft schema.  It gives meta a whole new meaning



  •  No kidding! You didn't mention which platform it was! Magento is the one I struggled with for quite awhile. The EAV structure is pretty intense in that product. It became more efficient to use PHP and the Magento framework to do queries on the database than to actually use SQL and it still wasn't exactly easy to do ad-hoc queries. It's really annoying when half of the joins are on the same table!

     http://thedailywtf.com/Articles/Database-Changes-Done-Right.aspx



    [Allow me to introduce you to one of the Web's best-kept secrets: the A tag. -ShadowMod]



  • @toon said:

    @morbiuswilters said:
    I tend to favor having software engineers involved because, you know, that's their job.

    Well, we, being on a programming forum, would say that, wouldn't we? Not that I think you're wrong, but I do think it's a point a higher-up decision maker might actually count in favor of a "dynamic structure".

    I've found that it's possible to end up with an EAV on almost any project by asking the manager in charge a series of leading questions, e.g. "so... if we find ourselves having to maintain some sort of new number for each product, is it OK for that to require programmer intervention?" No IT management type worth his Scott Guthrie Gut-Busters Secret Decoder Ring is going to say "yes" to such a question. Unfortunately , the 100-1000% increase in cost associated with using an EAV instead of a more traditional schema with domain-specific column names is often untenable. (I'm estimating here, but reasonably.) IT management types look at expensive programmer time saved by using EAV over the lifetime of the application, but if you're taking twice as long you should, that "lifetime" is by no means guaranteed, and using EAV should not be allowed to sink the entire metaphorical boat.

    Despite these problems, I have advocated EAV in situations in the past where I perceived the alternative to be significantly worse, e.g. gross problems with cross-version compatibility.



  • @morbiuswilters said:

    there are times I feel a "dynamic" system is going to be suboptimal and that it's better to have a good team that can add features as necessary.

    Agreed. Rather than trying to make the most flexible system on earth, just plan better for refactoring. Documentation and unit tests go a long way to easing this process, but many developers would struggle in vain to make "the most flexible system on earth" than write some documentation or a test suite. Ironically, the argument is usually that they don't have any time to implement those things.



  • @morbiuswilters said:

    In terms of ACID and failover, non-relational DBs don't match up; most don't even use redo logs so a crash can corrupt your database.

    Agreed, not all are created equal. CouchDB is certainly more resilient, while MongoDB is almost intentionally not. Typically, their superior sharding and replication make up for this, but you have to be actively aware of them and be using them to get any benefit.

    @morbiuswilters said:

    In terms of schema-less design: sounds nice and flexible, but tends to lead to chaos. Indexing is often poor.

    I'll use CouchDB again as an example; It has nothing BUT indexes. You can't query it in the normal sense, there is no "table scan". You essentially build indexed views in the form of map/reduce functions.

    @morbiuswilters said:

    Okay, you can use a schema: but if you're defining a schema for different types of products, then you could just as easily convert those types into tables, then join to a base table. You get the benefit of a mature RDBMS.

    If the attributes are simple, like weight or number of pages, that's true. But what if an attribute needs to store a list of publication dates that you don't know the length of ahead of time. Are you going to store those dates, separated by commas, in a text field? Surely, breaking out a new table just for publication dates on a single product isn't worth it.

    @morbiuswilters said:

    I think the strongest argument for non-relational databases is if your data has no inherent structure; then a lack of schema comes in handy. However, I'd also say that if your data has no inherent structure, you haven't worked hard enough to identify and normalize things.

    I agree and disagree. non-relational databases are the new hotness and ripe for abuse. However, you can do a lot of really useful, fast, things with a document database that still has structured data. For example, I could have a document that stores a blog post and then store all the comments as a list of objects within that document, saving hundreds of joins.



  • @Soviut said:

    For example, I could have a document that stores a blog post and then store all the comments as a list of objects within that document, saving hundreds of joins.

    Forgive me if I'm being dense here, but what's so bad about having a posts table and a comments table? One query for the post, a second to fetch the comments. I don't see where any of those joins are coming from.



  • @Daniel Beardsmore said:

    @Soviut said:
    For example, I could have a document that stores a blog post and then store all the comments as a list of objects within that document, saving hundreds of joins.

    Forgive me if I'm being dense here, but what's so bad about having a posts table and a comments table? One query for the post, a second to fetch the comments. I don't see where any of those joins are coming from.

    Or just a single "text entry" table with a foreign key for "parent text entry" which is nullable to indicate it's a post and not a comment. Then you can trivially add comment threading too, and you're not wasting a table.

    On a related note, I love blowing SQL neophyte minds by demonstrating that you can join tables to themselves. For some reason, wherever idiots learn SQL, they never mention that.



  • @blakeyrat said:

    On a related note, I love blowing SQL neophyte minds by demonstrating that you can join tables to themselves. For some reason, wherever idiots learn SQL, they never mention that.

    Agreed that it will be a mind blower for many (not just neophytes, I have seen people with a few years not realize this). What I find to be "problematic" is a solution for artibrarily deep recursions of this type, especially when there are "Trees" involved. This is not to say that it "cant" be done, merely that it is not always easy to get the desired results (especially in an efficient mannrer when filtering across layers is involved).


  • ♿ (Parody)

    @TheCPUWizard said:

    What I find to be "problematic" is a solution for artibrarily deep recursions of this type, especially when there are "Trees" involved. This is not to say that it "cant" be done, merely that it is not always easy to get the desired results (especially in an efficient mannrer when filtering across layers is involved).

    You guys use SQL Server, right? Does it not have hierarchical queries? Oracle uses START WITH / CONNECT BY / PRIOR clauses that makes them pretty easy.



  • @boomzilla said:

    @TheCPUWizard said:
    What I find to be "problematic" is a solution for artibrarily deep recursions of this type, especially when there are "Trees" involved. This is not to say that it "cant" be done, merely that it is not always easy to get the desired results (especially in an efficient mannrer when filtering across layers is involved).

    You guys use SQL Server, right? Does it not have hierarchical queries? Oracle uses START WITH / CONNECT BY / PRIOR clauses that makes them pretty easy.

    Not overly familiar with ORacles implementation, but SQLServer does have some capabilities [exmpamples: http://msdn.microsoft.com/en-us/library/bb677191.aspx]. For simple requests (as shown in the samples - DUH), it is pretty straightforward. But (at least in my experience) when the queries get more complex, the queries get exponentially more complicated and quickly become (again for me) very difficult to performance tune or even follow.



  • @morbiuswilters said:

    @Soviut said:
    (Cue someone who's never actually used anything beyond a relational database telling me I'm wrong)

    I have used non-relational databases, and you're mostly wrong. Non-relational databases are far behind RDBMS in terms of virtually every feature. I definitely wouldn't recommend it for this use case.

    When trying to read about "NoSQL," "non-relational," etc., and when trying to listen to the proponents of this crap, I often get the sense that these people are really pretty ignorant of RDBMS. At worst, this is due to sheer laziness; in a few cases, maybe there was a dickhead DBA who ran the "NoSQL" guy off at some point, and that's more understandable, but still not excusable. Having worked with RDBMS, EAV, and with all sorts of homegrown and hashtable-based things that were supposedly alternatives to RDBMS, my overall opinion is that RDBMS is a very good thing. Like any dependency, the costs associated with adding a relational database to a project need to be weighed against the benefits. But if you do decide to tolerate a dependency on something, with all of the attendant rigamarole, it probably makes good sense for that "something" to be fully relational. If I'm going to go to the trouble of licensing and using your thingy, it had better not be some stupid hashtable wrapped up in a bunch of innuendo about the RDBMS people (who, by and large, know what they're doing).



  • @bridget99 said:

    @morbiuswilters said:
    @Soviut said:
    (Cue someone who's never actually used anything beyond a relational database telling me I'm wrong)

    I have used non-relational databases, and you're mostly wrong. Non-relational databases are far behind RDBMS in terms of virtually every feature. I definitely wouldn't recommend it for this use case.

    When trying to read about "NoSQL," "non-relational," etc., and when trying to listen to the proponents of this crap, I often get the sense that these people are really pretty ignorant of RDBMS. At worst, this is due to sheer laziness; in a few cases, maybe there was a dickhead DBA who ran the "NoSQL" guy off at some point, and that's more understandable, but still not excusable. Having worked with RDBMS, EAV, and with all sorts of homegrown and hashtable-based things that were supposedly alternatives to RDBMS, my overall opinion is that RDBMS is a very good thing. Like any dependency, the costs associated with adding a relational database to a project need to be weighed against the benefits. But if you do decide to tolerate a dependency on something, with all of the attendant rigamarole, it probably makes good sense for that "something" to be fully relational. If I'm going to go to the trouble of licensing and using your thingy, it had better not be some stupid hashtable wrapped up in a bunch of innuendo about the RDBMS people (who, by and large, know what they're doing).

    Refering to technologies as "crap" clearly shows that one is not sufficiently informed to make an unbiased judgement.  Yes, many of the "solutions" these technologies proposed are hyped when compared to relational RDBMS and in many cases they are used inappropriately; but that has no bearing on the quality of those technologies when used in other appropriate situations. I am a big fan of RDBMS, but I also use alternatives when appropriate. There have definately been a few cases where I chose and RDBMS [specifically SqlServer] and later realized that a "NoSQL" type solution would have met the needs quite well, reduced development complexity (and therefore TCO), and generally been a better solution.



  • @Soviut said:

    Are you going to store those dates, separated by commas, in a text field?
     

    Welcome to ASP.NET profile properties. Welcome to PowerSchool custom fields. (To be sure, ASP.NET stores profile properties as a serialized array, while PowerSchool uses some nether-reaches-of-ASCII control character.)

     EAV would be a huge improvement on either of these. For starters, it can be indexed. (Want to see some performance suckage? Try making a directory of your users based on profile properties. You know, things like first and last name ... )

     The true beauty of PowerSchool's approach cannot be appreciated until you access the database via ODBC from a non-Oracle client (a.k.a. "the rest of the world") and the client spits the dummy.



  • @TheCPUWizard said:

    Refering to technologies as "crap" clearly shows that one is not sufficiently informed to make an unbiased judgement.

    No, it doesn't. It just means one is of the opnion that non-relational database management systems are crap. The fact that your opinion differs, doesn't mean the other party didn't think theirs through. Maybe you're the one who's biased in favor of non-relational DBMSes.

    Case in point: I happen to think that all versions of Microsoft Internet Explorer I've seen so far, are crap. That doesn't mean I don't think they do the job, or even that I think they're badly written. I mean, if I ever tried to write a browser it would be about an order of a magnitude worse than IE v1. However, it also doesn't mean I don't know anything about IE browsers. In fact, I use IE7 almost daily to try to get my websites to render decently in it. And although I'm not an expert, I like to think I know a thing or two about software, having been an amateur programmer for almost two decades now (amateur being the key word, I hasten to add). So uninformed, I think I am not. Nonetheless, I am of the firm opinion that Internet Explorer is a piece of shit. I'll grant that I may be a bit biased, but I haven't met an IE fan in years, but I've met dozens of Firefox and Chrome fans. I haven't met a Firefox or Chrome hater in my life but I've met quite a few IE haters. So when I express my opinion that Internet Explorer is a piece of crap, I could probably do with a little subtlety, or a little nuance, but from my point of view I don't think I'm biased, and I also don't think I'm insufficiently informed.

    TL;DR: get off your high horse.



  • @toon said:

    TL;DR: get off your high horse.

    Hmmm, that wasn't really necessary or polite, or even helpful in making my point. I was going to edit that and make it "strike through", but I was too late. Sorry :S



  • @toon said:

    I haven't met a Firefox or Chrome hater in my life

    Haven't been on this site long, have you.



  • @blakeyrat said:

    @toon said:
    I haven't met a Firefox or Chrome hater in my life

    Haven't been on this site long, have you.

    I don't believe I've ever met any of you! Seriously though, no, I haven't. If I had to venture a guess, I'd say people are Firefox haters because it's OSS?


Log in to reply