Is it good to add new column in table WP_USER - Or - should I add stuff in metauser table?
I was questioning this because there is a WP function
/* Get full WP_User object instance. */
$user = new WP_User ($user->ID);
Will that work as well after adding column in WP_USER?
If you want custom fields to be added to your user, use the usermeta or create a new table with username as primary key. This would allow you to be future proof in terms of updates.
Ask yourself this: does the data I want to store have a 1-1 relationship with a user table entry? If so, put it in a separate table indexed by user ID (call it [prefix]_user_auxdata or something like that), and add other 1-1 data there, should the need arise again. If not, put it in usermeta as a key-value pair.
The reason to store it separately is because this future-proofs your database from changes WordPress may want to make to the users table. It avoids a potential conflict by eliminating the possibility of one in the first place.
Related
I have three tables, and I'm just looking for a way to make this work.
tbl_campaigns has the columns "id" and "campaign". This one is fairly straight forward, it's just campaign names with an ID number that is auto-incremented so they have unique IDs.
tbl_users has an "id" column so each user has a unique ID number, standard stuff.
tbl_permissions creates a new row whenever a new user is created. This means its "id" column has unique ID values that match to the ID of a user in 'tbl_users'. The columns have been named to match the ID value of a campaign each time a new one is created, for example, the column "campaign_1" is relevant to the campaign in 'tbl_campaigns' with the ID of 1. The idea is this table data is filled with either 1's or 0's.
If a row with the ID of 1 has the number 1 for the column "campaign_1", then the user with the ID of 1 is approved for the campaign with the ID of 1 in the campaign table. If it were 0 then they're not approved for it. The same logic applies for columns "campaign_2", "campaign_3" etc..
Anyways, the issue I'm having is displaying this information on a front-end, as I only want the user to be able to see the campaigns they are approved to run in a drop-down list. When the user is logged in it stores their User ID in a session, I'm not sure if there's a way around it with this method.
Is there any way to get around this? Please note I've done this in procedural PHP as I'm still in my early days, so if anyone has a solution along these lines it would be much appreciated. Sorry if it's a little confusing. I am aware it's a bit ham-fisted, but I just want it to work first.
I believe that your schema needs to be improved, as the table structure should not have to change every time that you add a new campaign.
keep tables tbl_campaigns and tbl_users as they are
create table tbl_permissions with 4 fields (id, user_id, campaign_id and permission)
To check if a user has permission use a query like this:
SELECT permission FROM tbl_permissions WHERE user_id = ? AND campaign_id = ?
So, every time you create a campaign add a corresponding record to the tbl_permissions table. No need to add a new column.
I think the best practice to do this is as follows:
- Create HTML to show to the user(if you don't have it, let me know so i can work on one you can use)
- Create JS archive that will be in charge of calling PHP file and show the result in your HTML(if you don't know how to make it let me know so i can help you)
- Create PHP file, this is going to be in charge of consulting your data base and give the result disired for your select (if you don't know how to make it, let me know)
It is pretty easy to make this work, let me know if you need more help.
I'm a Laravel noob rewriting some old code to Laravel.
I have a system for managing purchases and games and I'm writing the store method of the PurchaseController. The form for creating new purchases contains data about the purchase and an array with data about the games.
There is a many-to-many relationship between games and purchases: a purchase can contain many games and a game may be linked to multiple purchases.
The thing is that the game may already exist in the database. I want to do the following:
Insert the new purchase into the database (this part I got sorted out already ;))
Check if the POSTed name of the game already exists in the database.
If it exists, attach it to the newly inserted purchase. If it doesn't exist, insert it and attach it to the newly inserted purchase.
I don't want to update the game if it already exists in the database, just to attach it to the purchase.
I've looked into firstOrCreate but that doesn't do what I want. It checks on all the arguments you feed it, you can't just make it check only the name (this issue basically).
The undocumented method updateOrCreate does accept two arrays (one for attributes to check on, another for values to insert) but it updates the record if it exists, which is not what I want.
So, is there a nice, proper way to do this with Eloquent or do I simply need to manually write some code that checks if the game exists in the database and inserts the game unless that's the case?
EDIT:
It seems that this is possible with firstOrCreate after all in Laravel 5.3: https://github.com/laravel/framework/pull/13236
firstOrCreate is what you need, but you can feed it just the game name, then attach it to your purchase.
$game = Game::firstOrCreate(['name' => $gameName]);
$purchase = new Purchase(['otherArgs' => ...]);
$purchase->games()->attach($game);
I was probably overthinking this too much. The following code does what I want:
// Insert games (unless they exist) and attach to new purchase
foreach($request->games as $game) {
$gameModel = Game::firstOrNew(['name' => $game['name']]);
if(!$gameModel->exists) {
$gameModel->status_id = $game['status'];
$gameModel->note = $game['note'];
$gameModel->save();
}
$gameModel->purchases()->attach($purchase->id);
}
I just thought maybe there was a nicer/shorter way to do this.
I want to create a posting system to a profile. I created a database for storing all users posts each user have a table.
Ihad created another database for storing the comments of each posts. My logic is to create each table in the comments database and store each comment in that.
Is there a logic to link the post and the comments. I thought to use mysql last insert id but it will return last id which will create error because one of the post will not have a table.
Is there any other way?
Another way would be to have a single table for posts, and identify a user post in the table using a userid column. To find all posts by a particular user, simply query by the user's ID. By doing so, you have a single table to manage, and you can do a lookup easily. If you create separate tables for each user, you have to create additional logic to first figure out which table to use. If a user is removed, you delete a table, rather than simply removing some rows from a common table.
The same logic applies to the comments table - add columns for postid',commentid,userid`. Again, a single table contains all the comments. To find comments on a particular post, you would do a simple query such as
select comment_text
from comments_table
where postid = ?
The whole purpose of using MySQL is to leverage relationships between entities, i.e. a user owns posts, a post is linked to comments.
If you do not want to use a relational schema like this, take a look at NoSQL DBs.
You have a couple options here:
Add a user_id column to your posts table, and a post_id, and user_id column to your comments table. You can then setup foreign keys with one-to-many relationships.
Only use a single table that has (in addition to your existing) a user_id, and type column. Type will define comment/post/etc. This can be defined with intermediary tables as a number mapped to a CONST, string, or any other way that you see fit (intermediary best option imho).
Vary the above example and use 2 intermediary tables to match users to posts and comments to posts (possibly also users to comments).
I have a multi-client level PHP application that I wrote. This application has many database object just like any other PHP app. But since it is a multi-client level app, I have different client requirements every time we on board a new client. There are couple common object (aka accounts) that host most of the client information. But blmost, every time I want to add new client to the database, this new client is going to require a new column in the accounts databases added because they will have some unique data. There are standard required data (ie. account_name, status......), but some data are unique and labeled different based on the client business type.
Currently, what I have to do to accommodate the requirements is
Alter the accounts table and add this new column manually.
edit the PHP script where I display the account information and display the content of the field like so
if(!empty($row['new_filed']))
echo 'Single Client Required Field: ' . $row['new_filed'];
if the field is editable, then I have to add rules to the edit/add form to do a data validation check before save.
I am trying to build a front end tool that will does that automatically for me. This way I can have an admin "not a programer" go the the front end tool and add a new field and that field will be displayed in the selected section of the selected page.
From the front end tool I want to be able to say add a custom field called "brand_c" and make it of a type varchar(100). Then on the page that is called "account_info.php" in the section called "Other" display this field with the label "Brand" only if the client = 'XYZ' so if the data belong to client 'ABC' do not display the data since this column is custom only for 'XYZ'.
I understand this is a wide question but what I am looking for is any help of how such a thing can be build (were to start from?). This is something that most of the big CRM do "ie. Microsoft CRM Dynamic, Salesforce.com ...) have it. How can I architect something like this?
Thank you
The first step you will need to do is design the tables properly, so basically you need to know how to design table to support dynamic fields and the field will be able to validate/handle such such data.
What I did with my application(dynamic application where the UI fields can be configured in the application's admin) is saving the configuration in the database, each time there is a transaction, the page will fetch the configuration for the selected biller and it will generate the required fields. and when the form is submitted, the application will again fetch the configuration and make validation based on the setting in client_field
Account table *Contain information such as account
account_id //primary key of this table
account_name
account_status
Client table
client_id //primary key of this table
account_id //foreign key:account table
client_name
client_status
you can add different column for the client depending on your requirement, but make sure not to add the required UI fields in this table, instead create the table like below
client_field table //will contain table that can be defined/configured
field_id //primary key of this table
client_id //foreign key:client table
field_name //the field name that will appear in the user interface
field_title //appear when on mouseover on the field
field_datatype //this can be text,integer,date,boolean,etc
field_type //field input type: this can be a textbox,datepicker,dropdown list,etc
field_required //flag to indicate whether the field is required
field_display //flag to indicate whether the field will appear/hidden in the user interface
field_defaultvalue //default value to set when the page renders
field_minvalue //minimum value the field will accept: only acceptable when dataytpe is integer/double
field_maxvalue //same as field_minvalue description instead it will check the maximum integer/double value
field_maxlength //max length for the field
field_order //order of the field in the interface
field status //activate or deactivate the field
You can add additional column but you need to make sure it will be fluid and not redundant.
let us say, you have field_type dropdown list, you need to create another table, lets call it
field_dropdown
id //primary key for this table
field_id //foreign key from client_field
dropdown_value //the value that will be used in the dropdown list when selected
dropdown_description //the description that will appear in the dropdown list
dropdown_order //order of the item
dropdown_status //flag whether this record is active/inactive
You might be wondering how to save the data if this is the case, the data must be saved in another table, lets call it
client_information
id //primary key for this table:
client_id //foreign key from the client table
field_id //foreign key from client_table.
value //the value from the user interface
this way, when you save a new client, each field in the client_field will add a new row in the client_information table along with the value inserted by the user
the challenges in designing this kind of application are:
it is quite hard to develop (lots of condition and mapping, and require alot of time)
you will need to properly configure the fields in order for it to properly work
proper system design,architecture, and flow otherwise it will ruin the dynamicity of the system
you will need proper documentation so that you will understand which is which.
the process will be linear for all the clients except if you can alter your own flow by saving them into the database
the PROS for this design is:
once it is finished, you do not require anymore developer to add additional code except for software enhancement such as feature that is not supported when it was released.
the application will be dynamic and adding any field will be easy and maintainable via the admin module
I am not saying this is the MUST DO, but this is my suggestion on how to develop application that requires dynamic data fields, and so far from my experience in developing one, it did work well just as long it is well design and developed.
Instead of adding additional fields as a new column into your accounts table, you could create a new table, say extra_data, with for example the columns account_id, data_label, and data_content. This way you could save as many extra pieces of data per account into that table, and fetch it in account_info.php.
I am currently working on a system that would allow users to add additional custom fields for the contacts that they add.
I wondered what is the best and most efficient approach to add such ability?
Right now what I was thinking was to have 1 table per users (with foreign keys to a "main" contacts table) and then adding a column for each custom fields that the user adds (since I don't expect to have more then 100-200 users per database shards [sharding is easy since every users never see each-other's content in this system]), although I am not 100% sure that this would be the right solution for such problems.
Maybe you could try to have one separated table to store a reference to the user, plus the field name and value, this way you will be able to have lots of custom fields.
If you go with Boyce-Codd, you separate the information and store them into a table.
Means one table for all users with a foreign key.
One table per user would lead to hundreds or more tables with possible repeated information.
You need to have one table named USERS that stores the id of a user and fixed info you might want. Then, you could have a CONTACT table, that stores the type of contact user might create, and one matching table USER_CONTACT that matches the user unique id with the id of the contact that was created.
With this, you could have advanced data mining on all the information stored, like nowing how many contacts each user created, who created more, etc...