We have a Vbulletin 4 forum as well as a gaming CMS (not Vbulletin CMS). We want to connect the database of these systems, integration with CMS.
My question is that: Is it better to make separate database for each one and then integrate two system together or put both in one database? Which one is better and lighter?
I would not recommend to use only one DB.
Each CMS (I assume vb forum IS a CMS) should have its dedicated database (but the DBs can be hosted on the same serv).
Each CMS uses plugins and has a very special way to work with the database, so basicaly they would not be able to share information directly via database.
Many CMS on the same DB = risk of conflict.
(depending what do you need to integrate) You need to use a bridge, that's safer.
Related
I'm building online examination system and i want to use accdb for database. My question is will accdb allow multiple students to read the test from the database?
not clear what you mean by on-line? Do you mean you are building a web based applcation of some sort?
Access does allow multiple users to work against the database at the same time. This typically means that you split the database into a front end (application part) and the back end - a accDB with just the tables.
And you can use the access database (engine) to drive data for a web site. However, you don't and can't use VBA or the access forms for this purpose.
Since you ONLY useing the tables and not anything else releated to Access when you build such a on-line system? Then in most cases, little if any reason exists to use the access data engine, since any of the business code and UI will be built with different tools then Access. And every web site hosting these days offers MySQL, or SQL server or some other database.
These other database systems are far more approcilate and work better with multi-user operations.
So, keep in mind when you use the term "Access", you are talking about two parts:
The data base engine - (ACE, or previous called JET). This data engine (like most database engines) does not provide any UI, reporting or anything, but is just a system to hold the tables and data. You then write the web based "on-line" software with asp.net, or whatever technology stack that you are familier with.
The 2nd part of access is the so called IDE (integrated development enviroment). That part of access lets you write code, build forms, and build reports. However, that part is not web based, and thus using the term "on-line" does not really apply here. Access IDE when used is strictly 100% desktop only.
In fact, often, if you need a multi-user applcation, we often will build + use MS-Access to build that windows desktop software, but will still choose to use a server based database system like SQL server or mySQL.
So, access alone does not really give rise to a "on-line" system, and that would require that you adopt a set of web based development tools.
I have made a django web app (postgresql backend) for internal use for one of my clients in New Zealand.
They have told me that they would also like it to be used by one of their branches in Malaysia (it will need to be connected to the same database). The problem is that apparently in Malaysia the internet is really unpredictable and there is a lot of downtime.
So here is the question, what would be the best way for keeping the Malaysian branch running when their internet is down and having their version of the database synchronised with the main database back here in NZ?
What you are trying to do is to synchronize your data and schema across multiple (2 in your case) postgresql databases.
There are a variety of solutions to do that depending on exactly what you want to achieve. This is a good place to start - http://www.postgresql.org/docs/devel/static/high-availability.html
and the summary of the different solutions and each solution's pros and cons are listed here -
http://www.postgresql.org/docs/devel/static/different-replication-solutions.html#HIGH-AVAILABILITY-MATRIX
Im wondering what will be the best way to organize my DB. Let me explain:
Im starting a new "big" project. This big project will be composed by few litle ones. In general the litle projects are not related to each other, they are just features of the big one.
One thing that all the projects have in common is the users that are going to use it.
So my questions are:
Should i create different DB for each one of the litle projects
(currently each project will contain 4-5 tables)
How to deal with the users? Should I create one DB for all the users
or should i
duplicate the users table in every DB? Have in mind that the
information about the users is used a lot in every litle project,
it's NOT only for identification purposes.
Thanks in advance for your advice.
This greatly depends on the database you choose to use.
If these "sub-projects" are designed to work as one coherent unit, then I strongly recommend you keep it all in the same database. One backup, one restore, one unit.
For organizational purposes, if you are using a database which supports it, select a different Schema per project. PostgreSQL and SQL Server are two databases (among others) which support this effortlessly.
In the case of a database like MySQL, I recommend you pick a short prefix for each subproject and prefix all tables accordingly. "P1_Customer" for example.
Shared data would go in it's own schema or prefix, like Global or something like that.
Actually, this was one of the many reasons we switched our main database from MySQL to PostgreSQL. We've been heavy users of both, and I really appreciate the features that PostgreSQL offers. SQL Server, if you are in a windows environment, is a great database IMO as well.
If the little projects are "features of the big one" then I don't see a reason why you wouldn't want just one user table for the main project. The way you setup the question makes this seem true "If there is a user A in little project 1, then there must be a user A in the 'big' project." If that is true, you should likely have the users in the big db instead of doing duplication unless you have more qualifying details.
i think the proper answer is 'it depends'.
Starting your organization down the path of single centralized system is good on many levels. I think in general i would recommend this.
however:
if you are going to have dramatically different development schedules, or dramatically different user experiences with the various sub projects, then you may be better off keeping them separate.
I'd have a look at OpenID or some other single sign-on protocol depending on the nature of your application. OpenID includes a mechanism called "attribute exchange", which allows applications to retrieve profile information from the OpenID provider.
This allows you to create a central user profile repository, with an authentication scheme, and have your individual apps query that repository for profile information.
The question as to how to design your database is hard to answer without more information. In most architectures, "features" within an application tend to be closely linked - "users" are related to "accounts" are related to "organisations" etc.
I'd recommend looking at the foreign key relationships to answer this question. If you have lots of foreign keys, build a single database for all tables. If you have "clusters" of foreign keys, and you want to have a different life cycle for each application (assuming the clusters map neatly to the applications), consider separate databases.
By "life cycle", I mean mostly the development lifecycle - app 1 might deploy weekly, app 2 monthly, app 3 once only and then be frozen.
I'm working on a site managed by Umbraco. I need to store data about images and clients. I don't think there is any way I can store that data in the existing tables.
Is there any reason I shouldn't add the tables I'll need to the Umbraco database, rather than creating a separate DB? I like Umbraco so far but the documentation is a little thin and I haven't found any suggestions one way or the other.
TIA
I have built a site using Umbraco, with a separate application with a database of vehicles. I used the same database as Umbraco is using, and prefixed all my custom app tables with a few letters to distinguish them easily (eg: vehicles_xxx)
I have had no problems with this arrangement, and don't believe there's much risk involved. Of course you'll need to take care when upgrading Umbraco (never upgrade in the live environment before fully testing, and preferably do it locally anyway), however its unlikely an upgrade script will ever alter or delete any tables that it does not know about.
There's heaps of doco available for umbraco now - much more than when i started.. however a question like this is always best for the forums. :)
all the best
greg
You might use the Umbraco API to store and retrieve your data and enjoy the ease of not having to worry bout tables and much more. Or you create your own tables. Do as Gregorius says - using umbraco db is fine.
Your choice depends on:
do you have a lot of data?
do you have a large relation model?
If not - then go with Umbraco API
The rest of the answers you'll find on http://our.umbraco.org
/Jesper Ordrup
I'm hoping you can help.
I'm looking for a zero config multi-user datbase that my winforms application can easily upload to a webserver folder (together with 1 or 2 classic asp pages) and am looking for some suggestions/recommendations.
The idea is that the database will be used to collect feedback entered by people filling in the asp pages. The pages will write to the database using javascript.
The database will subsequently be downloaded again for processing once the responses are in.
In Summary:
It will mostly run in MS Windows environments.
I have a modest budget for this and do not mind paying for such a database.
No runtime licensing costs.
Should be xcopy - Once uploaded to a website folder it should be operational.
It should not have a dotnet CLR dependency.
It should support a resonable level of concurrent access. Average respondent count would be around 20-30 but one never knows.
Should be a reasonable size so that uploads/downloads to and from the site will be reasonably fast.
Would appreciate your suggestions/comments
Many thanks
Abz
To clarify - this is a desktop commercial application for feedback management in a vertical market. It uses SQL Server as the backing store.
The application currently provides feedback management from email and paper feedback. I now want to add web feedback capability. Getting users to to make their SQL servers accessible to a website is not at option at this time as I am want to make getting up and running as painless as possible.
I intend to release a web based implementation of the software in the near future but for now am looking at the above as a pragmatic way to provide web based feedback collection.
SQLite comes to mind. It meets all of your stated requirements, is open source, and has a liberal license (public domain).
http://sqlite.org/
I would use 'normal' database (say MySql, Postgresql, Firebird, etc.) on server. Instead of copying files to server your winforms application would create custom tables (or even custom databases). After collecting data you could just get it back to your application using plain old SQL.
why reinvent the wheel ? If you want to collect feedback and stuffs from users of your app and if they are connected to internet, it might be a better idea - and in the long term cheaper - to use a service like wufoo. We recently switched from homegrown setup to wufoo and are very pleased. Check it out.
Otherwise you might want to take a look at sqlite orfirebird. Both of them are very robust, and have ADO.NET providers. Firebird scales from a single user to full blown client server system and has no .NET dependency.
If you really don't want a DB/SQL Solution, you could try simple text files and ftp/xcopy files down and parse them into the back-office server as needed. ASP/VBScript or ASP.NET can create the files to store the basic feedback comments. Need to consider security of course!