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 :)
Related
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.
I am creating an application with a click to call button on an html page.
There will be one person manning the phone. I want this person to be able to set a variable with a boolean value on my server: 1 is available, 0 is unavailable.
I could create a single field SQL table but this feels like overkill, or I could read and write to a text file containing just one character.
What is the most correct way to store a single value?
I know it seems like overkill to use a small database table for this.
If your application already uses a database, this is by far the best way to proceed. Your database technology has all kinds of support for storing data so it doesn't get lost. But, don't stand up a database and organize your application to use it just for this one data point; a file will be easier in that case.
(WordPress does something similar; it uses a table called wp_options containing a lot of one-off settings values.)
I suggest your table contain two columns (or maybe more), agent_id and available. Then, if you happen to add another person taking telephone calls, your app will be ready to handle that growth. Your current person can have agent_id = 0.
If you have a DB set up, I'd use it.
That's what DB's are for, persisting changeable data.. otherwise you are basically writing your own separate DB system for the sake of one setting, which would be uberkill in my eyes!
There is value in consistency and flexibility.. what if I suddenly need to store an expected return time? How do I do this in a text-file, how do I differentiate the column? How do I manipulate the data? MySQL already answers all these questions for you.
As a team member, I'd expect most of my dev colleagues (and new hires) to know how to use MySQL.. I wouldn't want them to have to work with, extend or debug a separate bespoke file persistence system that I had tacked on.
If you are worried about having lots of one row tables dotted about, you could use a single table for miscellaneous singular config variables which need updating regularly.
We have a table like this:
Table: `setting`
Columns: `key_string` VARCHAR, `value` VARCHAR
And could store your variable as
['key_string' => 'telephone_service_available', 'value' => '1']
In this specific case a simple file check (Exist a file or not) is probably the most simple way you can do here. And it also has the benefit to easily check if the file exist or not, you don't have to read file contents.
But if you need just one more information, you have to go a complete other way.
Depends on what you try to do afterwards with the information.
If you use it within a web-application store it in the session.
Or try a flatfile-database like SQLite (no active DBMS needed). Its easy and you can extend it very easy.
Or just a bipolar information with creating a file. If the file is not there is is off.
I'm working on a web application that uses PHP for it's code,and MySQL for it's storage engine. When working on my data model, I realized that I have a small issue with the handling of 'default' data.
I designed the MySQL schema to include the defaults, which made sense at the time because I was mostly manipulating the data 'by hand' -- it's a year later that we got around to adding a Control Panel to let others change the data.
The issue becomes how to handle 'default' values that are needed for some objects. Technically, leaving things 'null' is also a default, but it wasn't one that particularly concerned me before now.
If I use the MySQL defaults, when I insert a new value I have to immediately turn around and query it to get the 'real' data out of the database. If, on the other hand, I set my defaults up in PHP, I start violating DRY by having defaults in two places. And if someone ever does a 'quick' fix and changes them in just one place, I could wind up with some pretty 'interesting' bugs to debug. At the same time, I can't remove the defaults from MySQL, because the really are part of the data schema, and need to be left in it.
I'm willing to bet I'm either overlooking something, or making an invalid assumption somewhere, but I don't know what it is. Anyone have any advice on how to handle this?
Edit:
For clarity, my PHP code might be something along the lines of:
$foo = new foo();
//Add in instance-specific data
$foo -> save;
Foo's save method would then run the query:
INSERT INTO FOO (bar1, bar2)
VALUES (:bar1, :bar2)
But that only inserts 2 of the (many) variables that Foo uses. All this does is set me up in the 'default' state. At the moment, I then have to run:
$foo= Foo::getFooWithId($foo->id); //I know I should use a DBA; this is legacy code
And $foo is then populated with the data that's been set up in the database. E. G. bar3 and bar4 have defaults that aren't set when first creating the object -- users can change them later if they want to (and probably will), but they aren't part of the 'default' object.
Should I move those defaults into PHP? Leave them in MySQL and pull out of it? Violate DRY by putting them in both places? Or am I missing a fourth, better option?
You didn't show us an example query, but I'll assume what's wrong.
If you write your insert queries in PHP in such manner that you omit the elements that have default values, MySQL will take over and add them for you.
So, say you have a table with columns id, user and comment. Let's say that comment has a default value. What I'm saying is that you can make an insert query where you'd specify just the id and user (or probably just user, if id is the primary, auto-incrementing index), and the comment will automatically receive the default value you set in your table definition.
EDIT
Whatever works best for your app design, really... See where will they be used the most and keep them there.
But a single rule I'd follow is: don't have the defaults in more than one place, especially if they're overlapping (as opposed to extending).
I am building an PHP/MySQL app and I am allowing users to create their own custom (as much as they want) profile data (i.e. they can add any amount of info to their profile with additional textboxes, but there is a "CORE" set of user profile fields)
For example, they can create a new textbox on the form and call it "my pet" and/or "my favorite color". We need to store this data in a database and cannot obviously create columns for each of their choices since we don't know what their additional info is before hand.
One way we think that we could store all "addidional info" they provide is to store their additional info as JSON and store it in a MySQL text field ( I love MySQL :) )
I've seen Wordpress form builder plugins where you can create your own fields so I'm thinking they must store the data in MySQL somehow as NoSQL solutions are beyond the scope of these plugins.
I would love to stick with MySQL but do you guys think NoSQL solutions like MongoDB/Redis would be a better fix since for this?
Thanks
One way to approach this is to use a single table using the EAV paradigm, or Entity-Attribute-Value. See the Wikipedia article. That would be far tidier in most respects than letting users choose a database schema.
You could create a table of key value pairs where anything not in core would be stored. The table would look like: user_id, name_of_user_specified_field, user_specified_value;
Any name_of_user_specified_field that starts showing up a lot you could then add to the core table. This is referred to as Entity-Attribute-Value. Please note, some people consider this an anti-pattern.
If you do this, please add controls to limit the number of new entries a user can create or you might find someone stuffing your db with lots of fields :)
MySQL can handle this just fine. If the additional data is always going to be pulled out all together (i.e. you will never need to get just the pet field without any other additional fields) then you can store it serialized in a column on the users table. However, if you want a more relational model, you can store the extra data in a separate table linked by the user ID. The additional table would have a column for the user ID, additional field name additional field value, and whatever else you might want with it. Then you just run a JOIN query when getting the profile to get all of the extra fields.
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.