I have this code $table->integer('card_id')->unsigned()->index(); in a table that I created using Laravel framework. Just to make sure what does the index()?
It's the way to say to the Laravel Migration to add indices to that column, in order to get faster results when searching through that particular column.
It's a common procedure in DB design when building tables. Just "index" some particular columns if you plan to make searchs in the table using those columns.
I just realized you added that "indexing" tag to your question and that the description of that tag answers your question.
A little bit more explanation to the answer:
It means the database server will create, well, an 'index' on that column. It makes queries faster for that column - so usually you'd use it on your primary key for instance. But maybe you find out you're looking up users by their email address a lot so you might add an index to that too.
There is a small performance hit for the database server maintaining the index (it has to update the index when you write a record to the db) - so you usually use them only where needed.
Related
i'm looking for an 'best practice approach' for addressing database rows. I'm using PHP.
I'm working on a settings framework. If a dev wants to know if a specific setting is set he can just call Settings::getSetting(1); and he will get the value from the users settings.
The 1 here is the ID of the corresponding database row. ID is the only key in the table and the only unique feature.
My problem is: a dev needs a value from a setting but he doesn't want to look the ID up in the DB. My absolut fav approach would be to use statics: Settings::getSetting(Settings::SETTING_FONT_SIZE);
Creating statics implies to care about a mapping and this could result in errors. (Someone is entering a new setting in DB and forgets to also add it to the mapping).
I could create dynamic constants using define() but this constants also need to be known (but it is more elegant than dealing with IDs).
Is there a way to address a specific row without caring about a mapping and with code completition inside an IDE?
If necessary, I can change the database table
thank you in advance!
EDIT:
The database table i'm talking about has two columns. The first is the ID (unique, primary, autoincrement) and the second is called 'value' and varchar.
EDIT2:
"forget this, it is not possible what your are looking for" is an acceptable answer :)
I've got 2 frameworks (Laravel - web, Codeigniter - API) and 2 different databases. I've built a function (on the API) which detect changes on one database (from 2 tables) and apply the changes in the other database.
Note: there is no way to run both web and API on the same databases - so thats why I'm doing this thing.
Anyway, this is important that every little change will recognized. If the case is new record or delete record - its simple and no problem at all. But, if the records exists in both databases - I need to compare their values to detect changes and this section become challenging.
I know how to do this in the slowest and heavy way (pick each record and compare).
My question is - how do you suggest to make it work in smart and fast way?
Thanks a lot.
As long as the mysql user has select rights on both databases, you can qualify the database in the query like so:
SELECT * FROM `db1`.`table1`;
SELECT * FROM `db2`.`table1`;
It doesn't matter which database has been selected when you connected to PHP. The correct database will be used in the query.
The ticks are optional when the database/table name is only alphanumeric and not an SQL keyword.
Depending on the response-time of the 'slave'-database there are a two options which don't increase the overhead too much:
If you can combine both databases within the same database by prefixing one or both of the tables, you can use FOREIGN KEYS to let the database do the tough work for you.
Use the TIMESTAMP-field which you can set to update itself by the DB whenever the row gets updated.
Option 1 would be my best guess, but that might mean a physical change to the running system, and if FOREIGN KEYS are new for you, you might wanna test since they can be a real PITA (IMHO).
Option 2 is easier to implement, but you still have to manually detect changes to deleted/rows.
In CodeIgniter I am looking for a way to do some post processing on queries on a specific table/model. I can think of a number of ways of doing this, but I can't figure out any particularly nice way that would work well in the long run.
So what I am trying to do is something like this:
I have a table with an serial number column which is stored as an int (so it can be used as AI and PK, which might or might not be a great idea, but that's how it is right now anyway). In all circumstances where this serial number is used (in views, search queries, real world etc.) it is used with an three letter prefix. So I can add this in the view or wherever needed, but I guess my question is more on what would be the best design choice. Is there a good way to add a column ('ABC' + serial) after queries so that it is mostly transparent to the rest of the application? Perhaps something similar to CakePHPs afterFind() hook?
You can do that in the query itself:
SELECT CONCAT(prefix, serial_number) AS prefixed FROM table_name
I'm looking to create a PHP script that creates a new table within a database that would be tied to a label and then within the table there would be rows of data relating to the status of the label. However, I'm not sure how I can get the PHP script (or MySQL) to increment the name of the table. All I can find is a lot of detail on auto incrementing columns for rows.
Thoughts?
You're doing it wrong. If you have scripts that, during the project live phase, create and delete regular tables, more often than not it is an indicator of bad design.
If you're keen on OOP, you may consider a table like a Class definition, and each row as an object (or an entity, if you wish) - i know it is a stretch, but it has some similarities.
Take some time to read about database normalization and database design, this project and everyone after this will benefit much more than spending time to research a working solution for the current problem you are facing.
Users can do advanced searches (they are many possible parameters):
/search/?query=toto&topic=12&minimumPrice=0&maximumPrice=1000
I would like to store the search parameters (after the /search/?) for an email alert.
I have 2 possibilites:
Storing the raw request (query=toto&topicId=12&minimumPrice=0&maximumPrice=1000) in a table with a structure like id, parameters.
Storing the request in a structured table id, query, topicId, minimumPrice, maximumPrice, etc.
Each solution has its pros and cons. Of course the solution 2 is the cleaner, but is it really worth the (over)effort?
If you already have implemented such a solution and have experienced the maintenance of it, what is the best solution?
The better solution should be the best for each dimension:
Rigidity
Fragility
Viscosity
Performance
Daniel's solution is likely to be the cleanest solution, but I get your point about performance. I'm not very familiar with PHP, but there should be some db abstraction library that takes care relations and multiple inserts so that you get the best performance, right? I only mention it because there may not be a real performance issue. DO you have load tests that point to an issue perhaps?
Anyway, if it is between your original 2 solutions, I would have to select the first. Having a table with column names (like your solution #2) is just asking for trouble. If you add new params, you have to modify the table columns. And there is the ever present issue of "what do we put to indicate not selected vs left empty?"
So I don't agree that solution 2 is cleaner.
You could have a table consisting of three columns: search_id, key, value with the two first being the primary key. This way you can reconstruct a particular search if you have the ID of a saved search. This also allows you to expand with additional search keywords without having to actually modify your table.
If you wish, you can also have key be a foreign key to another table containing valid search terms to ensure integrity. Whether you want to do that depends on your specific needs though.
Well that's completely dependent on what you want to do with the data. For the PHP part, you need to process it anyway, either on insertion or selection time.
For really large number of parameters you may save some time with the 1st on the database management/maintenance, since you don't need to change anything about your database scheme.
Daniel's answer is a generic solution, but if you consider performance an issue, you may end up doing too many inserts on the database side for a single search (one for each parameter). Too many inserts is a common source of performance problems.
You know your resources.