Separating MySQL content via PHP on a "per-country/user preference" basis - php

Okay, I'll lay this out simply:
I have one database that has content in it but I need to set up a conditon where if the user has selected Britain instead of the U.S. or vice versa -- some content will not show. This condition can be applied via a checkbox in the backend like so.
"Hello, I'm a paragraph" show in [x] Britian [x] U.S.
I'm not looking into actual IP Addresses or anything of that sort as the site will simply redirect to root/uk or root/us subfolders upon the user's selection on the index page. What kind of a unique parameter would I have incorporate in the db or php?
Thank You!

Add a column in the database display_content, make it a EMUN and set the values to 'britain','usa','all' then make the adjustments in your code to check for Britain/USA. you can either choose to display all, Britain or USA.

That's an interesting problem. Because although it's language oriented, it's not actually I18N related - you're talking about deny access to content based on a language preference, not displaying localized content.
Here's one idea: use a permission model
Create two permissions such as "read-enUS-content" and "read-enGB-content"
Based on the user's selection, grant them the correct permission for the length of their session (which you can persist if you wish via cookies or user prefs)
It would then be the responsibility of the application to allow/deny the content based on their permissions.
Then the question becomes, how do you connect content to permissions? There are a multitude of ways, but one approach is a bitmask column.
00
||
|+--- Read enUS bit
+---- Read enGB bit
Which might look like this when implemented
Articles
+----+---------+-----------------+
| id | content | read_perm_level |
+----+---------+-----------------+
| 1 | foo | 1 |
| 2 | bar | 2 |
| 3 | baz | 3 |
+----+---------+-----------------+
This means that 'foo' is only readable by enUS, 'bar' is only readable by enGB, and 'baz' is readable by all.
But you could also do a full permission's table and connect the content to it that way.

The most straightforward model for this would be an associative table in your database. You'd thus have:
paragraphs (paragraph_id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, paragraph_text TEXT, ...) ENGINE=InnoDB;
paragraph_countries (paragraph_id INT UNSIGNED, country_code CHAR(2)) ENGINE=Innodb;
When saving the paragraph settings, perform these steps:
BEGIN WORK (to start a transaction)
DELETE FROM paragraph_countries WHERE paragraph_id = ...
(foreach checked country): INSERT INTO paragraph_countries (...)
COMMIT (to commit the transaction)
To select paragraphs relevant to the current country, simply JOIN to the associated table with the appropriate country code.

Related

Best MySQL Database Structure for a Yellow Pages Site

Im building a yellow pages site. I tried multiple database structures. Im not sure which one is best. Here are few I considered,
Saving all business data - name, phone, email etc in one table, list of tags in another, and mapping data id and tag id for tag-data relationship in a third table. I found this cumbersome since I'll be doing most things directly in the database (at least initially, before launch) and hence distributing everything can be problematic in my case. This one is a clean solution I must admit though.
Saving biz entries in one table with a separate column for tags (that'll contain comma separated(or JSON) tags for every entry). Then retrieving results using like query or full-text search for a tag. This one will be slower and will get more slow as db size increases. Also its not easy to maintain - suppose if I have to rename a tag.
(My Preferred Choice) Distributing biz data in different tables based on type - all banks in one, hotels, restaurants etc in separate tables. A separate table for all tags containing a rule for searching data from the table. Here is a detailed explanation.
Biz Tables:
college_tbl, bank_tbl, hotel_tbl, restaurant_tbl...so on
Tags Table
ID | Biz Table | Tag Name | Tag Key | Match Rule (col:like_query_part)
1 | bank_tbl | Citi Bank Branches | ['citi','bank'] | 'name:%$1%$2%'
2 | restaurant_tbl | Pizza Hut Restaurants | ['pizza','hut'] | 'name:%$1%$2%'
3 | hotel_tbl | The Leela Hotels | ['the leela'] | 'name:%$1%'
I'll then use 'Match rule' in like query to fetch results from 'Biz Table' for 'Tag Name'.
Im going forward with the third approach. I feel its simple, reduces the need of third data-tag relationship table, renaming is easy and performance won't get down if table has limited entries - say 1 million max per table.
Im scratching my head for the last 15 days to find the best structure and feel this one is pretty good in my case.
Please suggest a better approach or if this approach could have some issues later on.
Use Number 1. Period, full stop.
The mistake is "doing things directly in the database" rather than developing the API first.
Number 2 has one advantage -- FULLTEXT search. That can be tacked onto #1 after you have have a working API and some data to play with.
Number 3 (multiple similar tables) is a fisaco. Numerous Q&A ask about such; the reply is always "NO".

How to dynamically load code in php + database

For some time now I'm thinking about a nice way on how to dynamically load code in php based on database entries. I've tried to look up something related, but couldn't really find anything that answered my question(s) thoroughly. I'm using Laravel - not sure if this might be a subject to solve this particular problem.
See the following code for "example data" where I tried to give a quick overview over the database structure. So for a game, lets say we have characters that can be at a location. Any location basically looks the same. You have a form to write a message at this location - nothing fancy. But then there might be some exceptions. For example you might have a location, that implements some more logic such as listing all online characters (+ showing their current location's name.). Or a location might show some other additional content.
This is what I came up with so far, but neither seems optimal:
Creating different tables for different types of locations (this seems very bad to me actually).
Create another table, f.e. modules, and have a many-to-many relationship with the location table. the modules table would then have entries for a location that tell the application what to "execute". F.e., a location might have the entries thread, for allowing to post messages, list, for showing an overview of online characters and their locations, trader, to allow some gameplay mechanics etc.
To me the second option seems to be kind of the right way of achieving what I want to achieve. I would have classes, functions etc. that would represent these modules. But it too seems very hardcode-y. Meaning, that for one in the code behind I would have to distinct between the values which I might or might not want to change in the future, which then would require a lot of refactoring. Because I have to distinct between strings, this design is prone to typos and what not...
character:
id | location_id (nullable) | name
---------------------------------
1 | 1 | Test
location:
id | name
----------------
1 | Location #1
2 | Online Characters
For the above presented version I would add:
modules:
id | name
---------
1 | thread
2 | list
3 | trader
location_modules:
location_id | modules_id
------------------------
1 | 1
1 | 3
2 | 2

Designing Flexible SQL Schema [for Quests]

What would be an efficient way to store "Quests" in an SQL database? Let's say the context is RPG. (Here was a previous question: How to store Goals (think RPG Quest) in SQL)
To summarize a Quest may be a combination of the following:
Discover [Location]
Kill n [MOB Type]
Acquire n of [Object]
Achieve a [Skill] in [Skillset]
All the other things you get in RPGs
The answer listed out in the link was:
For the Quest table:
| ID | Title | FirstStep (Foreign key to GuestStep table) | etc.
The QuestStep table
| ID | Title | Goal (Foreign key to Goal table) | NextStep (ID of next QuestStep)
I actually think it's pretty neat, but I have two things I would like to add:
Let's say I want to create it so that a quest can only be active only on certain days (e.g. M W F only) and/or active only at a certain time span (e.g. Halloween). What would be the ideal way of doing this?
Another thing: Let say I want to have a quest with two steps and a quest with 8 steps. We can create a table that is 8 columns wide but we would have lots of empty space. And what if the stars align and I needed an 9 step-wide quest?
The QuestStep table actually has a NextStep, sort of like a linked list, but what about Quests that you can do out of order?
P.S: As you can see it is potentially read-heavy, and the schema is potentially... non-schematic. Is NosSQL a vying option? (Redis seems memory only, so I'll more likely go with MongoDB)

Multiple Customer Databases plus Global Customers

I am developing a (potentially) large-scale tracking software that tracks customer data, along with tickets that are created for tasks associated with said customers. This system is written entirely in PHP, and the database is MySQL.
The system currently supports multiple "locations" (stores for example), and each has its own table for customer data (in the same database, each database can be host to a whole different business' installation). For example:
store1_customers
customer_id | customer_firstname | customer_lastname
----------------------------------------------------
1 | John | Doe
2 | Bill | Bob
store2_customers
customer_id | customer_firstname | customer_lastname
----------------------------------------------------
1 | Jill | Smith
2 | Jimmy | Person
This works great for keeping locations separate for different business needs. However, we are running into the need to have "global" customers for other instances that can be accessed from any location, while keeping other customers separate.
The two options I can think of are to either make a new "global_customers" table that can then be pulled from separately, or to merge all of the data into one large table.
I have concerns with both methods. The first would require a new column in every table that references the customer to determine which customer table to pull from. For example, store1_tickets would have to know whether to pull the customer ID of 1 from store1_customers or from global_customers. This seems to be a bit dirty, and I think would present problems with trying to do my multiple JOIN queries.
The second method of making one giant table concerns me in two ways: the first being the size of the table (each table so far can have potentially 20k+ records, and there are 7 locations for just one particular installation of the "software"). I know this point may be moot due to how MySQL works and can handle it. The second concern is merging the existing data. I see it being a nightmare since each table has a 1-20k customer ID, and I would have to have some way of changing thousands upon thousands of existing records in other tables to match the new numbering of this table.
Is there a better way, or more proper way of accomplishing this? I'm sorry if this question does seem subjective, but it does come down to a database problem and how to handle the data in a reasonable way.
Merge all the data into one large table. That is how databases are designed to be used.
For data migration, you will end up with new Keys, there is no way around that. You could, however, add a new column to store the 'legacy' ID. This is just some of the pain assoicatied with normalizing a database. Take the pain now rahter than presisting with a sub-optimal database design.
Customer type would be another column within the cusotmer table, probably (but depending on your requirements) this would be a FK to a CustomerType table.

Preserving old data changed by user

I have a users table that has the following fields: userid, phone, and address. Since this is user data, I'm letting the user change them whenever he wants. Problem is I'd like to keep track of those changes and preserve the old data too. Here's some of the ideas I considered:
appending the new data to the old data and using a separator like a pipe. When retrieving the field, I would check for the existence of that separator and if exists, get the chars after it as the new data. (feels cumbersome and doesn't feel right)
setting up a different changes table with the following fields: userid, fieldname, fieldcontent. When/if a user changes data (any data), I would log the event in this separate table under the user's userid, and the name/id of the field and the old content of the field, then I can now overwrite his old data in users with the new. If I want to find all changes made by this user, I would search the changes table by his userid. Problem with this is that I'm mixing all data changes (of all fields) into one table and so the fieldcontent field in changes has to be text to accommodate the varying field types. This still seems better than the first idea, but still not sure if I'm doing the right thing.
What other ideas are there or known best practices to keep old data?
Thanks in advance
Whatever you do don't do the first one.
The changes table is a better approach. It's also called an audit or history table. I wouldn't do a history of key-value pairs however. Instead do a history per relevant table. You can do this in application code or via database triggers. Basically whenever an insert, update or delete happens you record which happened and what data was changed.
Table user:
id
username
email address
phone
address
Table user_history:
id
change_type (I, U or D for insert, update or delete)
user_id (FK user.id)
email address
phone
address
date/time of change
optionally, also store who changed the record
A very simple way that we have used to track such changes is this:
users_history`
userid
changenumber smallint not null
changedate datetime not null
changeaddr varchar(32) not null
phone NULL,
address NULL
primary key on (userid, linenumber)
Each time you INSERT or UPDATE a record in the users table, simply INSERT a new record in the users_history table. changenumber starts at 1 and increments from there. changedate and changeaddr could be used to track when and where.
If a field value has not changed, feel free to put NULL in the respective users_history table field.
At the end of the day, your app does not need to change or store bulky history data in the users table, but you have all if it at your fingertips.
Edit:
This does preserve the old data. See the following example where the user started with a given address and phone, and then 4 days later updated the address, and 5 days later updated the phone. You have everything.
Current users record:
100 | 234-567-8901 | 123 Sesame Street
Sample History Table
100 | 1 | 2009-10-01 12:00 | 123-456-7890 | 555 Johnson Street
100 | 2 | 2009-10-05 13:00 | NULL | 123 Sesame Street
100 | 3 | 2009-10-10 15:00 | 234-567-8901 | NULL
The simplest way to implement this will be have another table just for history purpose, a snapshot. You don't need to mirror all the fields, just
change_id // row id (just for easy management later on if you need to delete specific row, otherwise its not really necessary)
user_id // Original user id
change_time // time of change
data // serialized data before change.

Categories