Home » RADICORE development » Workflow » Problem with db
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
 Re: Problem with db [message #1003 is a reply to message #18] |
Sat, 28 July 2007 14:06   |
zamolxes
Messages: 9
Registered: July 2007
Location: Transilvania, Romania
|
Junior Member |
|
|
I suggest you directly tell that amateur ISP company, what it will take them to become professionals.
You'll find them at http://www.unitedinternet.de
Unless you are fluent in German, press the 'English' button on the top right. There is a mail adress in the imprint where you can contact them. I am very interested what they will reply.
They host several million web users, (including many major companies from Germany) and claim to be the world's largest web hoster. Of course database creation there is not done by hand and naming conventions follow the standards they have developped.
I do not (yet) know how rigid their naming policy is, but if they adhere to their principles and you adhere to yours, this will mean, that none of their several million customers will ever be able to use Radicore, nor will I.
If you don't plan to have Radicore deployed at a larger scale, but have its use confined to those ISPs who happen to be compatible with your design principles, and if you are more than happy with your income generated from this source, then this may not be an issue for you.
Otherwise a little bit of reconsideration might be in place.
HF
|
|
|
|
| Re: Problem with db [message #1004 is a reply to message #1003] |
Sat, 28 July 2007 15:02 |
AJM
Messages: 2382
Registered: April 2006
Location: Surrey, UK
|
Senior Member |
|
|
Popular databases such as MySQL, PostgreSQL and Oracle allow multiple database schemas per connection, and the Control panel software used by most of the ISPs that I have seen specifically allow multiple databases with whatever names you want, as does the popular phpMyAdmin administration tool. Those ISPs who specifically disallow multiple databases are, in my experience not offering a professional service, so I do not want to waste any of my valuable time in modifying my software so that it runs in their cheap, amateur environment.
I am not bothered about the potential loss of revenue that this may cause as I have more than enough projects from professional companies wh consider multiple databases to be a normal setup.
I'm sorry if you find my views inconsiderate, but perhaps you could as your ISP to explain their single database restriction. This is an artificially imposed limitation which has nothing to do with any software, so they should justify why they have imposed it.
|
|
|
|
|
|
|
|
| Re: Problem with db [message #1007 is a reply to message #18] |
Sat, 28 July 2007 20:42 |
zamolxes
Messages: 9
Registered: July 2007
Location: Transilvania, Romania
|
Junior Member |
|
|
"It is possible to merge all the tables into a single database, but the effort is too huge and I'm not going to do it."
If merging the tables into one database involves considerable work from your part, why do you write such misleading things in your Programming Guidlines, that lead to the conclusion, that it can be achieved by configuration.
"I have been working on large applications for many years, ..."
So have I, really complex applications, able to cope with terabytes of information under very stringent conditions as to performance, accuracy, timeliness, requiring exact design.
"... and the concept of a separate database for each subsystem is just standard practice. This is how professional systems are written, it is how professional databases work, ..."
Experience shows, that there is no such thing as 'standard practice'. Instead, there exist quite a number of standard practices, each in its own right, and applied according to circumstances.
According to Charles Darwin neither the most intelligent, nor the strongest will survive, but the most adaptable. This is also true for software.
The professionality of a software product is unrelated to the size of he application for which it is used. From what you say, I conclude that only large applications can be professional.
However ingeniously a product may be designed, its acceptance and success will strongly depend on its ability to adapt itself to the most controversial environments.
"... so low budget ISPs should not prevent the standard practice of professionals with their amateur restrictions."
Why don't you tell the ISPs? I'm not an ISP and telling ME what ISPs should do, or rather what they should not do, will not bring about changes.
In the meantime, could you answer these questions? If I try to have Radicore installed on one of our systems over which I have complete control, how much space should be allocated for each of the different databases? I have not read all your documentaion yet, but before I end up with another surprise, I rather ask this question now, and I'm asking it because after all I have read now, Radicore is oriented towards utmost professionalism: Will I have to distribute these databases over separate disks, since this is how professional databases work? And if so, can those disks be shared with other applications, or must they be dedicated to Radicore? This will help me estimate the number of hard disks I'll possibly have to buy, in order to make the framework run.
Best regards HF
|
|
|
|
| Re: Problem with db [message #1009 is a reply to message #1007] |
Sun, 29 July 2007 15:34 |
AJM
Messages: 2382
Registered: April 2006
Location: Surrey, UK
|
Senior Member |
|
|
Here are my answers:
- There is nothing in my programming guidelines which says that my software can be switched from using multiple databases to a single database with a simple configuration option.
- The comment in my programming guidelines about "where there is a restriction on the number of different databases which can be created" was for ADDITIONAL databases for new subsystems being written to run under the Radicore framework as I am aware that some ISPs do not allow more than 5 or so databases. The kind of people who will most likely benefit from using the Radicore framework are the ones who have total control over their web servers, so the petty restrictions imposed by some low-budget ISPs are of no concern to me.
- I have been writing administrative applications, primarily for the desktop and latterly for the web, for over 25 years. These applications involve heavy database usage, and it was standard practice in all of those applications to have separate databases for each subsystem. Thus to me this is "standard practice". My current project, for example, has 7 databases, 130 tables, 230 relationships and 1000 tasks.
- Databases such as MySQL, PostgreSQL and Oracle specifically allow multiple database schemas per server, it is possible for a single SELECT statement to access multiple databases through the use of JOINs, and their administration tools make the maintenance of multiple databases/schemas very easy. Any ISP who specifically disallows this capability is, IMHO, providing a less-than-optimal service.
- The databases within the Radicore framework are quite small, initially less than 2MB combined, and the only one which may grow significantly over time is the Audit database, but that depends entirely on how much data you write to it. If you ever reach any limits on database sizes it will not be as a result of a flaw in the Radicore framework.
- The Radicore framework does not FORCE you to distribute each database onto a separate server, neither does it disallow it. It even allows different databases to run under different databases engines, so you can have a MySQL database, a PostgreSQL database and an Oracle database all running under a single Radicore instance.
- The Radicore framework does not mind sharing a disk with other applications, and it will allow both the application code and the database(s) to reside on the same disk, therefore the minimum number of hard disks is 1 (one). There is no maximum.
|
|
|
|
|
|
|
|
| |
  |
Goto Forum:
Current Time: Tue Jun 17 18:09:07 EDT 2025
Total time taken to generate the page: 0.01781 seconds
|
Radicore Forum
Search
Help
Members
Register
Login
Home
