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.
Related
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.
I have 3 seperate modx evolution website. All 3 websites are completely different and therefore run off a seperate database. However for the news and events pages of each website i would like them to all run from the database of the 1 of the 3 websites. I this possible? is there an extra already created for this purpose?
I have looked into the possibility of using an RSS feed, but would rather have them running directly from the database as this would allow a news article to be added from any of the 3 websites.
Thanks,
Sean.
you can create your extra tables in one modx instance & access them externally ~ however they will need to be on the same file system. I am not aware of a method to do this VIA http/API etc. See here.
http://rtfm.modx.com/display/revolution20/Loading+MODx+Externally
What you will want to do is create your extra table and extend modx using xPDO, it's a fair bit of work to get setup initially but worth it in the long run. This is the best example for getting started, although you will not be extending anything [but modx] it does give you useful examples of creating your schema and registering it with modx.
http://rtfm.modx.com/display/revolution20/Extending+modUser
and
http://rtfm.modx.com/display/revolution20/Using+Custom+Database+Tables+in+your+3rd+Party+Components
Finally, there IS an extra that will generate all your schema files for you, however I can't seem to find what it is called... sorry. If you have multiple tables using foreign keys it may not be all that useful to you as it won't create the relationships in the files it generates.
I think it has to be possible, but didn't find anything useful yet...
Is it possible to run multiple websites with from 1 Kohana core? Basically all website's are the same, only the layout is different. (Just a different view-folder, (works)) and the content is a bit different. (This is based on constant SITE_ID that pulls it from the db, (also works))
The only two things are, how do I configure this in my bootstrap/index.php? I thought of checking the url. With that url perform a query on the table 'websites' (select where url = '$url') and get the right SITE_ID and view from that query.
In that way both x.com y.com and z.com will pull up the same index.php file. After that SITE_ID is defined and with that id the right content is loaded and the right view is used.
Also, how can I do this in combination with widgets. I have like 8 different widgets and each website displays 3 of those 8 over different pages. So x.com/a will display widget 'widget_1' and 'widget_2', x.com/b will display 'widget_2' and 'widget_3'. But y.com/a has to display 'widget_6' and 'widget_7' and y.com/b has to display 'widget_3' and 'widget_4'.
Is there a way this can be managed? I didn't worked a lot with widgets before and now I want to use it in combination with multiple sites...
Possible?
For multiple sites handled via database within a single instance; what you're doing is similar to a multisite CMS. I have experience developing CMSes, both of the single site and multisite sort; I can tell you through experience that developing a multisite CMS is significantly more complex than doing multiple instances of single CMS. I usually opt for the latter if having multisite is not a requirement from the client and the implementation is up to me.
Have you considered multiple instances of websites with separate folders?
For multiple instances of single sites, I suggest reading http://kohanaframework.org/3.2/guide/kohana/tutorials/sharing-kohana to get a better idea of how do go about having multiple sites with single (or even multiple core).
At my work we have two separate sites that are very closely related. One of them is a ASP/MSSQL site and the other is a PHP/Postgres site.
I want to create a REST API that everything from now on is built on top of. I would like it to be tied to both DBs so that it can be a a single point of retrieving and setting data.
I was thinking of using a DBA like Doctine to keep from writing queries in two different syntax. In the same system is it possible to tie parts of Doctrine to the MSSQL and other parts to Postgres?
If so, how? Any other thoughts on design are welcomed.
Within your application framework, you need to configure two separate entity managers, each of which will connect to a different database. More on entity managers at http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/configuration.html
The core architectural pattern is that your models are plain PHP objects, and the entity manager (Data Mapper) will read the mapping configuration to know how to map the models to a database.
If you're writing a REST based API it shouldn't really matter what the DB backend is. For example, if you write your API in a combination of Django and tastypie, you could simply swap out a settings.py config to work with both Postgres and MySQL... or even MongoDB if you so chose
The point is, a REST API is a generic solution that can be used by a multitude of languages, you should chose a framework that allows you the same flexibility in DB backends to implement.
I'm building an application (using the zend framework) where we will have multiple clients who login and use the application, and each of these clients will be storing lots of data about their users (I'm using MySQL btw).
Basically I'm wondering 2 things:
Is having multiple databases, one for each client (ie. ipd_client_CLIENTNAME) with identical tables a stupid idea? Or will it actually be more responsive (than putting everything in one database) if we have 50 clients with 20,000 users' data in 'their' database?
I've already managed to build the same system but all on one database, my model classes simply grab the name of the client logged in (in the model classes' init() method) and then dynamically change the name of the table they grab data from, is this going to be just fine?
If the "every client on the system gets their own database" makes sense, how exactly would I dynamically change what database my db models connect to (based on which client is logged in)?
In case this made no sense, here's an example of what the databases would look like in the two different scenarios (given 2 clients registered on the system):
Multiple Databases:
ClientA has a database called "ipd_clients_ClientA" with tables "users", "lists".
ClientB has a database called "ipd_clients_ClientB" with tables "users","lists".
Single Database:
ClientA has tables called "users_ClientA", "lists_ClientA".
ClientB has tables called "users_ClientB", "lists_ClientB".
Hopefully that makes sense.
Any help would be GREATLY appreciated, thanks!
i would use Solution 2, with multiple Tables for your clients in combination mit MySQL Master / Slave Replication.
MySQL Master Slave
If you want to use different Databases, you can use native functions of Zend Framework:
Tutorial multipe dbs
And than select the one for the client by some kind of prefix.
Although you accepted that answer, I beg to differ. I think having multiple database would be much easier to manage.
The way that tutorial uses multiple databases is far more complicated than it needs to be. The way I do it is by simply defining the client name in a root file (index.php?) and then my bootstrap uses this constant to load in the correct ini file.
If you start with the separation, you can then go on to using the same principles for caching data in separate structures far more easily.
Using separate databases would make it much easier to manage individual clients.
While ZF does have support for multiple database connections, I would not use them in this particular case.
It makes more sense to me to store a client_id (or site_id) in each of your data tables and use that to filter. Duplication makes it very hard to make application-wide changes. Whenever I see dynamically named tables like that, I usually think it's poor design.
For caching, just prefix any cache keys with the client identifier.