I'm creating a form in CodeIgniter that has a paired value- Companies, and CEOs. The idea is, while there is only one Company field with one CEO field below initially on the form, there is a button for me to create more pairs of Company-CEO fields. I have an idea for how to make that appear on the frontend, but I'm not quite sure which is the best way to store it on the backend.
I think in order to combine each Company and CEO field into one value for storing in the MySQL database, I could simply use CONCAT. However, I'm not sure if I should even bother creating such a value. In any case, how would I handle the fact that there are a variable number of Companies (and thus CEOs) for each record? Would I have to store Company and CEO within another value? How could such an array or tuple be handled in MySQL?
Point 1: Do not combine the values. It will give you headaches in code splitting and combining. Make two columns, one for company, one for CEO.
Point 2: In general, when using a database, any time you have a list it gets its own table.
The various JS libraries out there let you handle this with a grid.
Related
First, I'll ask the question:
Is it possible to make a value's type 'dynamic' by creating different tables with different value types and use a simple join query to fetch the correct table based on the type specified in a column?
Here is the context:
I'm building a sort of page builder where I want the "modules" to be dynamic in the sense that I can create new modules without having to modify the database in any way.
I envision 4 entities:
A field, which represents a single value of a specific type, for example a text field or a checkbox;
An entry type, which represents a group of fields to be used for an entry. For example, Article = Title + Content + Image.
An entry, which is the content defined by the corresponding entry type.
A value, which contains the data for one field for one entry, defined by the field's value type.
For the 'value' entity, I was planning on using multiple tables for each "type of value". "value_text", "value_integer", "value_boolean", etc.
What I wanted to do (and I think it's an anti-pattern in relational database) was to grab a value in the fields table to select the proper "value" table.
Here is an image of the structure I envisioned:
(imgur) UML Diagram of DB
So I'm looking for a way to make a single query to fetch the correct value for each field of a specific entry (by ID).
This means I have to access the assigned entry_type, fetch all the fields related to that entry_type, then fetch the value of each of those fields from the value tables based on the column 'value_type' of the fields table.
If this is possible, how can I achieve this? If it's not possible, what would be the best way to tackle this problem:
Make a first query to retrieve the fields, then a query for each field to grab the correct value? This makes a lot of queries to get the values of a single entry...
Modify the structure of the database to a more efficient set of relations, taking into account everything is dynamic...
Get rid of the idea of using mutiple "value types" and stick to using a more common everything-is-serialized-text approach.
Also, as this is one of my first questions on StackOverflow, please let me know if I asked incorrectly and how I should formulate this in the future.
Thanks for all of you who even take the time to read this :)
Before I start I need to say I know multi-valued fields are a bad way to store data. However, because of the data and what it will be used for it seemed the easiest way and this problem has been bugging me for a short while
I am building a database that has multiple different tables based on Candidates and their specialized job sector
I have multiple queries that take data from one table to another depending on inputted values
I have a table called TblClient, which holds all the client names
I have a table called TblCandidateSupport, within this table, I have a lookup field that holds multiple values from TblClient (only needed so I can see which candidate has been to which clients)
The problem I am having is when I run an append query to the values stored in the multi-valued field to another table called TblCandidateSupportAvailable.
I either get an error "An INSERT INTO query cannot contain a multi-valued field" or only get one value appending when I use.value.
The value that is appended from the TblCandidate will only ever be viewed.
What is the best way to carry the data across?
I have job in Talend that is designed to bring together some data from different databases: one is a MySQL database and the other a MSSQL database.
What I want to do is match a selection of loan numbers from the MySQL database (about 82,000 loan numbers) to the corresponding information we have housed in the MSSQL database.
However, the tables in MSSQL to which I am joining the data from MySQL are much larger (~ 2 million rows), are quite wide, and thus cost much more time to query. Ideally I could perform an inner join between the two tables based on the loan number, but since they are in different databases this is not possible. The inner join that is performed inside a tMap occurs after the Lookup input has already returned its data set, which is quite large (especially since this particular MSSQL query will execute a user-defined function for each loan number).
Is there any way to create a global variable out of the output from the MySQL query (namely, the loan numbers selected by the MySQL query) and use that global variable as an IN clause in the MSSQL query?
This should be possible. I'm not working in MySQL but I have something roughly equivalent here that I think you should be able to adapt to your needs.
I've never actually answered a Stackoverflow question and while I was typing this the page started telling me I need at least 10 reputation to post more than 2 pictures/links here and I think I need 4 pics, so I'm just going to write it out in words here and post the whole thing complete with illustrations on my blog in case you need more info (quite likely, I should think!)
As you can see, I've got some data coming out of the table and getting filtered by tFilterRow_1 to only show the rows I'm interested in.
The next step is to limit it to just the field I want to use in the variable. I've used tMap_3 rather than a tFilterColumns because the field I'm using is a string and I wanted to be able to concatenate single quotes around it but if you're using an integer you might not need to do that. And of course if you have a lot of repetition you might also want to get a tUniqueRows in there as well to save a lot of unnecessary repetition
The next step is the one that does the magic. I've got a list like this:
'A1'
'A2'
'B1'
'B2'
etc, and I want to turn it into 'A1','A2','B1','B2' so I can slot it into my where clause. For this, I've used tAggregateRow_1, selecting "list" as the aggregate function to use.
Next up, we want to take this list and put it into a context variable (I've already created the context variable in the metadata - you know how to do that, right?). Use another tMap component, feeding into a tContextLoad widget. tContextLoad always has two columns in its schema, so map the output of the tAggregateRows to the "value" column and enter the name of the variable in the "key". In this example, my context variable is called MyList
Now your list is loaded as a text string and stored in the context variable ready for retrieval. So open up a new input and embed the variable in the sql code like this
"SELECT distinct MY_COLUMN
from MY_SECOND_TABLE where the_selected_row in ("+
context.MyList+")"
It should be as easy as that, and when I whipped it up it worked first time, but let me know if you have any trouble and I'll see what I can do.
Whenever I'm considering the option of making a field's contents being extracted from a predefined list, should I make a new table to list exclusively those options, then make a query, then make a form-level lookup field to select it?
This seems like creating A LOT of tables and queries from those tables, just to have a lookup field. I have no idea what the normal number should be, or if there is a clever way of doing queries without creating new tables everytime that I'm not aware of.
For example: I have an Addresses table, and each address can be of three types: home, professional, other. Should I make a table exclusively to list those items and then reference it through a query and a lookup field in a form?
What's the procedure here? Thanks in advance!
Use table lookup when you are going to use this lookup in another entity or you are going to allow the end-user to edit entries of this lookup. In other cases, be free to confine yourself to use constant list of values.
Feel free to ask more.
I am considering a use case wherein every user of the application can create N number of forms with n different form fields of different data types. Each user can then receive form data in their respective forms. This data can then be updated, edited, searched, sorted etc.
I wonder, how do I design the DB architecture for this in MySQL.
My initial approach was to save form structure in serialized form in one table with form_id as primary key. Another table, data shall hold the records with columns: form_id, record_id, order, value. Here, order will be number denoting the position of the field in the form structure. value column shall have the value for that field. This approach caused me to have 10 rows (for a form with 10 fields) for 1 set of records. Also, I don't think such a query can be written to search records for a particular form.
I did think of using mongodb for this use case, wherein form structure shall be stored in an array and within that array, all records for that particulsr form shall be stored. I have never ever used mongodb, but I guess mongodb has some sort of restriction on size, if I store documents within a document. So, what is the best way to do this using MySQL (or any other DB perfect for such a use case)
Each mongoDB document is restricted to 16mb in size. If you needed each document to be bigger then you would need to adapt your design appropriately. MongoDb does also include GridFS which allows you to break larger files into chunks.
In your example, you could store the form fields as an array in mongoDB but you could also store them as an embedded document. Whichever way you choose to do it, your schema design in mongoDB needs to match your data access patterns.
It's easy to add new key:value pairs to mongoDB documents through your application. Pseudocode would be:
if user adds form field
db.collection.update({'id':1},{$addToSet {'newField':'value'}})
I know your question was about MySQL structure but I thought it worth showing how it could work in mongoDB (obviously would need to be adapted to your chosen language).