views:

113

answers:

4

This is my situation: I am constructing an ad-like application in Django and Mysql. I am using a flexible-ad approach where we have:

a table with ad categories (several categories such as home, furniture, cars, etc.)

  • id_category
  • name

a table with details for the ad categories (home: area, squared meters. car: seats, color.)

  • id_detail
  • id_category (the categ the detail describes)
  • name
  • type (boolean, char, int, long, etc.)

the ad table (i am selling a house. i am selling a car.)

  • id_ad
  • id_category
  • text
  • date

a table where i plan to consolidate the details of the ads (home: A-area, 500 sq-meters. car: 5 seats, red.)

  • id_detail_ad
  • id_ad
  • id_detail
  • value

Is this possible? Can I have a table of details for all the ads, even if details include numbers, texts, booleans, etc? Or would I have to save them all as text and then interpret them via code accordingly? Please express your opinions. Thank you.

+3  A: 

Relational databases doesn't support user-defined data types like OODBs do. I recommend you to have the details column separated into several others columns, as you'll increase performance and future usability and scalability.

Ben
Relational databases certainly can support user-defined types. Oracle and SQL Server are two SQL DBMSs that permit user-defined types. There is no fundamental reason why any RDBMS should not do that.
dportas
@David - Those are object-relational DBs. RDBs doesn't support user defined types. And OP is talking about mysql.
Ben
Object/Relational = Relational. A relational database can in principle support any type at all and they might just as easily be user-defined ones. SQL Server, MySQL and Oracle are strictly SQL DBMSs and not RDBMSs but there is nothing about the relational model that precludes user-defined types. Just because MySQL doesn't have them that doesn't make it a general rule.
dportas
@Ben, so you mean that for each detail, I would need a numeric, boolean, text and so on fields, and I would just use one? wouldn't this increase storage space?
poseidon
@David - If you're referring by 'user defined type' something like VARCHAR VALUE('xxx-yyy-zzz;;132'), that's not a user defined data type, that's a VARCHAR. I was talking about abstracts user defined data types found in OODBs just as an example. MySQL IS a RDBM, SQL Server and Oracle (just recently) support ORDs and they were, and still are (by ORD's definition) RDBMs. As for SQL DBMS, of course they are, SQL is, and will be, the common layer. But above that they're are 3 different buildings.
Ben
@poseidon - There's something you didn't specify, or clarify, are the details always gonna be the same or random?
Ben
@Ben the details are going to be defined for each ad category.For example:I define CAR in the table AD_CATEGORIES. Then, in the AD_CAT_DETAILS table, I define COLOR, NUM_SEATS, TRANSMISSION, FUEL, etc. each with a foreign key to CAR. Then, I create CAR ads in the ADS table, and for each I am able to define the details I previously stated in AD_CAT_DETAILS for CAR. All the custom values for the details of each CAR ad will be saved in AD_DETAILS, with a foreign key to the corresponding detail kind in AD_CAT_DETAILS, that is (COLOR, 'red'; TRANS, '4x4', FUEL, 'D'; SEATS, 4).
poseidon
@poseidon - And the problem is that, for example, houses ads doesn't have "seats", right?
Ben
@Ben - No. You can see entries in AD_CAT_DETAILS as detail definitions for each AD_CATEGORIES. You define CAR and HOUSE in AD_CATEGORIES, but you also define (name:SEATS, AD_category_ID:CAR) in AD_CAT_DETAILS. This means that SEATS is only a detail possibility for CAR.The problem is that when I create an ad, the main ad data is defined in a third table, ADS ('i am selling a car', AD_CATEGORY:CAR), but the info/details for this ad are saved in a fourth table, AD_DETAILS. In AD_DETAILS I wanted to have three fields: AD_id, DETAIL_id, value (for example: [24, SEATS, 4], [24, COLOR, 'red']).
poseidon
@Ben - the problem is that, as you can see, details can be numeric, boolean, varchar, etc.
poseidon
A: 

Consider having one table for each ad type. This is the old school RDBMS way to model the data you're describing. It means that you'll have to add a table to your database every time you add an ad type. I think you'll find this is not as bad as it sounds. The benefits of this approach will be less code written for data management and/or a better use of you object/relational mapping library (disclaimer: I've never used Django, so your mileage may vary, but this would definitely apply to other tools)

Paul Keister
A: 

It's a bit of a hack, but you can store any kinds of information you don't care about indexing in a text column in mysql. You can use either pickle if you don't care about the information being readable, or (better) jsonpickle, which is human readable and easy to access with jsonpickle.encode and jsonpickle.decode. We do this at my job, and it works swimmingly.

intractelicious
A: 

These tables look an awful lot like key-value pairs... in relational database design, this is a big no-no, you want to do what Ben is recommending.

Yet I've seen that a lot of web CMMSes use this sort of arrangement in their table structures. Almost as if they expect the tables to be structured that way. If Django wants you to solve the problem this way, you might have to do it that way. In which case the other comments on pickling data in/out of columns, or using a BLOB column, works well.

However, if Django expects tables this way, quite frankly, the Django designers didn't know a thing about how to use a relational database correctly or efficiently, and their framework should use a different database engine that operates on key-value pairs. It's a poor design, if they enforce the user/programmer into situations like that.

sheepsimulator
It's not unreasonable to build a secondary data management system on top of an RDBMS that supports it's own table definitions. If the requirement is for a flexible CMS for ad type definitions, that's what I'd do. However, I think the problem with the original question is that there's a desire to have it both ways: if the ad attributes are part of the RDBMS schema, then the entire ad content should be modeled properly. If the desire is to have a flexible CMS system, then the RDBMS schema should be concerned only with generic CMS. The danger lies in the middle path.
Paul Keister
@Paul - The main reason I put the third paragraph in my answer is more of a rant against CMSs and their inefficient design. If they use a lot of key-value pairs to, I don't know, _render all the page content_, then they shouldn't use a RDBMS for that _by design_. I don't think it's unreasonable to put it in, I think its poor design on the part of the CMS and should be fixed industry-wide. But a typical web developer can't fix that.
sheepsimulator