I have built a hosted point of sale system where you can create an account for your own store and manage your own users, etc.
To do this, I have implemented multiple databases, one 'master' to keep track of store owners and one for each of their stores.
The problem is, the hosting provided by the client who commissioned this does not allow creation of multiple databases through PHP. I figured using table prefixes will solve this. How do I go about implementing prefixes for each store's tables in Codeigniter? I would like to avoid 'hacking' the core of the framework, if possible.
Related
We are building a intranet web application in PHP with CakePHP.
However we have barely experience with CakePHP
Our Intranet will have two user portals.
Employee portal
Client portal
Both portals will use the same data but have their own user interface.
Employees can see other data than clients and vice versa.
We want to build a central core for both portals. For example, a single authentication system, a contact form, a notification functionality, same footer information, etc. We want to use this central core as much as possible so we don't have to rewrite code.
We use Git to manage our code. We want to make a branch for both portals and one for the shared core.
We hope you can give us some advise about how setting this up with CakePHP.
Is building multiple app's a good idea?
Or should we just run CakePHP and our core on two web servers? (one for each portal)
Or should we use plug-ins for the core functionalities?
Or should we use single controllers with multiple views (one for employee and one for client?)
Or something totally different?
Thanks for any advice
Eventually, you'll start noticing similarities between the 2 portals, and the code-base. If they are sharing same data, why don't you have a single code-base and have permissions around what users can see based on roles? We had to do this recently when we merged 3 pages into 1. 1 page was for admin, and the other 2 was for other roles. Then users started requesting features on page 2 that page 1 already has etc etc. it became a mess and we decided to consolidate these pages into 1, and have permissions around what each users can see based on their roles. Also read more about helpers as it will come handy, so you dont make your view bloated.
In my experience a portal is typically a very thin layer on top of some CRUD framework. I think the opportunity for code sharing between these two applications is very limited. You can share the authorization and authentication .. and that's about it and I don't know if sharing this part is a good idea (probably not).
If most of your code goes into building the HTML views you'll likely end up with two completely separate views for employee and client.
As Ayo mentioned... the permissions alone will separate the two user groups and you can take advantage of CakePHP's layout or the themes feature to give a totally two different look for each user group.
You may also want to take a look at CakePHP plugins feature. It allows you to easily add new functionalists to an existing app, without messing with the existing code base.
My aim is to write a collection of many webapplications, like google services (mail, calendar, docs, ...).
It will be written in PHP with Zend Framework (Version 2). I use MySQL to store data.
The service collection should always be extendable (new services) easy.
Is it useful to provide a own database for every service? They would have few tables only (more or less 3). That would mean that I have to use Zend's multiple database adapter.
The other solution is to use one big database for the hole collection. The advantages are that I can use foreign keys between the tables of different applications. I also could use the default database adapter.
All the applications are enmashed with each other close.
What makes more sense?
If you have enough databases from your provider you could use multiple databases, but if you have User accounts its better to create one main-Database for that.
Break the services out with one database each, including the service that identifies the users. All of the services should talk to each other via web services. This architecture will be the most flexible in terms of scaling pieces individually as well as maintaining the pieces individually.
It is impossible to give anything more specific in terms of architecture of such an application ecosystem without substantially more information about the project, and incidentally, that would be beyond the scope of this site to answer.
I have a Drupal Multisite set up with hundreds of sites. I want to make some tables shared (like banners, and roles) so I don't have to update hundreds of sites when changing a banner (for example).
I know this can be done using these strings in settings.php:
$db_url = 'mysql://user:pwd#localhost/example_db';
$db_prefix = array(
'default' => '',
'users' => 'subsite2_',
'sessions' => 'subsite2_',
'authmap' => 'subsite2_',
);
But ... what if I have a multiple database setup as well? I have one database that holds all shared tables .. So in that database, I have the Banners table - that I want to have all the other sites to use.
The reason for a multiple database setup is because the whole multisite setup consists of hundreds of sites (and will be thousands by the end of this year) .. so every database only holds about 20-40 sites.. I suspect a lot of these tables can be shared..
hope someone can help. thanks!
Marco
There is a walkthrough to setup something like this. It aims at sharing only the user data, but the principle can be extended to more or less all tables. Note that it uses a 'trick' on the table prefixing logic by prepending not only (or not at all) a table name prefix, but also/only a database selector using the dot notation, e.g. someDatabase.someTable. So I'm not sure how this would translate to a PostgreSQL backend. Also, it means that you're still restricted to a single database server, as there is (AFAIK) no mechanism to use two different database connections in a single Drupal instance.
As an alternative, you might try to find a solution from the database engine side of things by 'mapping' your shared tables into the different database instances via some kind of replication/mirroring feature. That way you could use the standard Drupal multisite setup, doing the sharing of tables 'behind the back' of Drupal. Not sure how/if this would work and what consequences this would have on locking and other concurrency issues, though.
These two modules which sound like they might help (quotes are from their project pages):
Data:
Data module helps you model, manage and query related sets of tables. It offers an administration interface and a low level API for manipulating tables and accessing their contents. Data module provides Views integration for displaying table data and Drupal search integration for searching table content.
Table Wizard:
The Table Wizard facilitates dealing with database tables:
It allows surfacing any table in the Drupal default database through Views 2.
Relationships between the tables it manages can be defined, so views combining data in the tables can be constructed.
It performs analysis of the tables it manages, reporting on empty fields, data ranges, ranges of string lengths, etc.
It provides an API for other modules to views-enable their tables.
It provides an API for importing data into tables in the Drupal default database (automatically doing the views integration above).
It is bundled with an implementation of this API, for importing comma- and tab-delimited files.
If you are using mysql 5+ mysql views is a good way of sharing data across multiple sites in drupal. Not only it allows to have shared content but individual sites can have there own content.
devbee tutorial on mysql views in drupal. contains the detailed tutorial on how to implement it using taxomony.
I'm writing an application that that I'm going to provide as a service and also as a standalone application.
It's written in Zend Framework and uses MySQL.
When providing it as a service I want users to register on my site and have subdomains like customer1.mysite.com, customer2.mysite.com.
I want to have everything in one database, not creating new database for each user.
But now I wonder how to do it better.
I came up with two solutions:
1. Have user id in each table and just add it to WHERE clause on each database request.
2. Recreate tables with unique prefix like 'customer1_tablename', 'customer2_tablename'.
Which approach is better? Pros and cons?
Is there another way to separate users on the same database?
Leonti
I would stick to keeping all the tables together, otherwise there's barely any point to using a single database. It also means that you could feasibly allow some sort of cross-site interaction down the track. Just make sure you put indexes on the differentiating field (customer_number or whatever), and you should be ok.
If the tables are getting really large and slow, look at table partitioning.
It depends on what you intend to do with the data. If the clients don't share data, segmenting by customer might be better; also, you may get better performance.
On the other hand, having many tables with an identical structure can be a nightmare when you want to alter the structure.
I'd recommend using separate databases for each user. This makes your application easier to code for, and makes MySQL maintenance (migration of single account, account removal and so on.)
The only exception to this rule would be if you need to access data across accounts or share data.
This is called a multi-tenant application and lots of people run them; see
multi tenant tag
For some other peoples' questions
I'm about to start a human resources web app system. My idea is to have the manager system and the website work with the same database, but make three or more "products" running with the same data. All in PHP and JavaScript.
My question is how can I get an authentication system like Zoho or Google, with one account for all services, and how can i store this. In a single table? LDAP? Which one?
If they're all on the same domain, then why treat them as one app? Either have a single auth table in your db or use a seperate db called by all three apps.
As for the actual auth system, there are many ways - the one you choose will depend upon your individual requirements.
If you plan on extending the apps provided, it might be worth looking at setting up an OpenID provider for your domain and/or allowing logins from other OpenID providers (like StackOverflow does).
I would look around for "PHP Authentication frameworks"
Login Sessions might be something to checkout.
I've rolled my own code for this in the past. Creating a schema for platform objects and defining permissions for what user/group can access what applications. Below is a simple schema for this type of thing.
Table Users
UserID
...
Table Applications
ApplicationID
...
Table Permissions
PermissionID
...
Table UserApplications
UserApplicationID
UserID
ApplicationID
PermissionID
...