I'm using PDFlib to generate tables. I break these tables based on sort column in the database. I want to add a heading to each page with the ever changing value of the sort column. How can I identify the sort column from the table as the tables are added to the pages ?
I worked out a solution that might be helpful to others. Instead of creating all the tables in one fell swoop I broke them into a separate array based on the sorting of the data then processed each table section independently one at a time.
Added table cells / rows to an array like so...
$tableArray[$sortA] = PDF_add_table_cell($p, $tableArray[$sortA], 1, $rowNum++, $sortB,$sortB_opts);
Then after all tables were built fit them to the pages like so
foreach($tableArray as $tbl){
$tabresult = PDF_fit_table($p, $tbl, $newllx, $lly, $newurx, $ury, $fit_opts);
}
Related
I've created a db in mySQL that stores many things, but specially images. The table name for storing the images is image, like so:
image (image_id, title, caption, filename, published_date, ...)
It's been almost 2 years and i've uploaded almost 5000 images into the table.
Now, i want to add a new functionality. I want to group similar images so when im looking at an image, i can also have the option to look at images that are similar.
I'm not sure if i need a new table or should i use the same table or both. Any ideas/suggestions on how it should be?
You should create another table with that similiarities.
Why can't it be the same table ? One record in You table can have many similiar records (so it will be adding many columns to that table or for every similiarity there will be another row in YOur table. So the only logical option is to create another table.
IdFromMainTable | IdOfSimiliarRecord
Later on You can show that similiarites in a view easily joining that table by IdFromMainTable. Or both IdOfSimiliarRecord and IdFromMainTable. [depends if u want to add 2 records for similiar records or just one for similiar pair]
It sounds like what you want to do is create tags for the images. There are a number of ways to do that, but adding the tags to the same table would prevent a whole lot of joins from taking place and would likely be faster. You could just store the tags as JSON (if you're using MySQL =>7.5.8).
I have a database like this:
Database example
My problem is I need multiple entries in the Substrate spot.
Kind of like a 3 dimensional database. I need to add in things like, hay, straw, potato peels etc. But it needs to be on the same spot like a list just for substrates. I cant go down the rows because that would be messing with the wrong mushroom and the only alternative I can think about is making substrate01, substrate02 substrate03 ... but since this can vary a lot, it makes no sense to make hundreds of rows just to reserve enough space for entries. One might only have 1 substrate and another might have 50 I need it to be dynamic.
Create another table, which contains a column for the key of the one row your trying to add to, and another column for the name, like substrate1, substrate2
So table one row might look like:
MushroomKey, mushroomname
Table two might look like:
Substratekey, mushroomkey, substratename
You might also want to learn about the normal forms of a database
If I'm understanding correctly, the general method to do this is to have a second table, linked by ID that contains one substrate. Then have one record per substrate in the second table.
If you need to display it all on one line, you can join the tables and use 'group concat' to assemble them.
Apologies if this is redundant, and it probably is, I gave it a look but couldn't find a question here that fell in with what I wanted to know.
Basically we have a table with about ~50000 rows, and it's expected to grow much bigger than that. We need to be able to allow admin users to add in custom data to an item based on its category, and users can just pick which fields defined by the administrators they want to add info to.
Initially I had gone with an item_categories_fields table which pairs up entries from item_fields to item_categories, so admins can add custom fields and reuse them across categories for consistency. item_fields has a relationship to item_field_values which links values with fields, which is how we handled things in .NET. The project is using CAKEPHP though, and we're just learning as we go, so it can get a bit annoying at times.
I'm however thinking of maybe just adding an item_custom_fields table that is essentially the item_id and a text field that stores XMLish formatted data. This is just for the values of the custom fields.
No problems if I want to fetch the item by its id as the required data is stored in the items table, but what if I wanted to do a search based on a custom field? Would a
SELECT * FROM item_custom_fields
WHERE custom_data LIKE '%<material>Plastic</material>%'
(user input related issues aside) be practical if I wanted to fetch items made of plastic in this case? Like how slow would that be?
Thanks.
Edit: I was afraid of that as realistically this thing will be around 400k rows for that one table at launch, thanks guys.
Any LIKE query that starts with % will not use any indexes you have on the column, so the query will scan the whole table to find the result.
The response time for that depends highly on your machine and the size of the table, but it definitely won't be efficient in any shape or form.
Your previous/existing solution (if well indexed) should be quite a bit faster.
I am developing HRM system using php/mysql. There is one table that has more than 30 coloums. Since there is no data repeating I didnt break it in to other tables. But after I design the designing part of the system, coustomer wanted to store data part by part. Now there are 6 form submittion instead of one form. But the problem is now I have to use one table for insearting six form's data.
I can continue this as I do. But I want to know whether it is technically ok. or do I want to break one table (35 coloums) in to 6 tables?
please share your thoughts.
Many form submissions that condense inte one table is not strange and should not be a reason to split the table.
30 columns in a single table should not matter either as log as the table is normalized
Splitting the table based on some UI feature would probably de-normalize the database
I can't work out what I should be doing here...
I have a database with around 20,000 records. Each of these records has about 20 columns to it.
I want to add around 20 or so additional columns to this database which would be on the lines of a load of different URLs for each record. Mostly, these will be blank.
What's the "right" way of doing this:
Add 20 additional columns (youtubeurl, facebookurl, etc)
(Benefits: only one URL call // Drawbacks: makes my database much larger)
Add an additional table with three columns - 'ID','URLType','URL' which I can additionally call?
(Benefits: keeps main table much smaller // Drawbacks: additional SQL query required)
What should I be doing?
Everything else being equal, I would go with option (2). This allows you to keep your data normalized and offers flexibility if you need to add more sites in the future.
FWIW, this does not require an extra query to SELECT data, as you can just JOIN to the other table. But of course, it would require extra INSERT / UPDATE queries.
Option 2 is a almost certainly the better option. It makes it easier for you to add new Url types in the future (just invent a new URLType instead of having to create a new column). Pages that use these urls then don't have to be modified to accomodate the new type of URL; they'll just pick it out of the table. In other words, you only have to make a change in one place instead of several.
If people mostly have only a few of these urls, splitting it into a separate table is almost certainly the way to go.
Everything you're adding is a URL. Each URL is related to one (or maybe more) of your current records. So either:
for URLs that have only one record-
urls table with url and FK to records table
or for URLS that can relate to more than one record-
urls table with url_id and url
linking table with record_id and url_id