Question

I am trying to figure out a design for a specific function in my system (It is apart of a cloud based service)

Essentially, I want users to be able to create their own psuedo-‘tables’ for a simple CRM entry/retrieval system that integrates with the system.

So I have 2 questions I am in need of help with

1. I am wondering how I will store data, I’ve thought of two layouts

   • making 3 tables which will store either text, integer or
     double for example

   cms_item_text – [id, heaqderID, data (text)]

   cms_item_int – [id, headerID, data (int)]

   cms_item_double – [id, headerID, data (double)]

   • OR cms_item – [id, headerID, data (text)] and I will (use the
     MySQL cast() function to convert from text to integer/double when
     doing order eg order by cast(data as signed integer) )

2. Now retrieval of the data is a different story. Since it is often in a table view, what is the best way to read from it? I’ve thought of it like this –

   SELECT barcode.data as barcode, price.data as price, notes.data as notes
   FROM cms_item barcode, cms_item price, cms_item notes
   WHERE (barcode.headerID = 1 and barcode.id = 1) and
         (price.id = 1 and price.headerID = 2) and
         (notes.id = 1 and notes.headerID = 3)
   

so that I could get results like

array("barcode" => "eg", "price" => "123", "notes" => "hello there")
array("barcode" => "no2", "price" => "456", "notes" => "yes")

What is the best design path to take?

Answer 1

I faced a similar problem with my application design. Essentially I had to allow the user to define the ‘tables’ in the database including specifying the data types.

I ended up going down the first approach, whereby i had a single table with multiple fields and different types which the user could define.

While i eventually got it all working it wasn’t smooth sailing. The queries got quite complex, and I had to use Dynamic SQL quite a lot in conjunction with building SQL queries from within my application.

The kicker for me and why i chose to implement strongly typed data field in my application (as opposed to storing everything in text fields) was the ability to perform SQL functions (AVG,MAX,MIN etc) on numeric data types.

So all i can say, is that either way you choose to go, there will be some things that are easy to implement and code, and others that are difficult. If you wish to pull out the data, and CAST the data either by using SQL functions or in code, depending on how big your application becomes there may be a lot of unnecessary validation checks when both storing and retrieving the data.

I would advise you to really think about what functionality your users need of the data in the DB, which is a decision you need to thoroughly investigate and will be dependent on your application and its intended use.

UPDATE

You may also need to consider the amount of data in your tables. I noticed you will be doing an ORDER BY using the CAST() function. Note that this is inefficient and may lead to slow queries.