concrete5 core team has a clear idea that they do not want to add prefix.

Reason 1. More server load

If you install multiple CMS into one database, your server get more load, and could cause the problem.



Reason 2. Hosting company chose to do so

There are plenty of other hosting company which offers multiple databases for inexpensive price.

And if a hosting company choose that they only allow you to create one database... that means your hosting company only wants you to install one CMS per database.

So concrete5 core team think that you should respect those hosting company.


The best idea is to switch the hosting company with multiple database (sometime, they cost only $5/mo), or have another account.

-----

Other solution.

However, I understand that you still want to do it, so only the solution is to install concrete5 first.

sad to hear this...

however, what do you mean by "install concrete5 first"?

"install concrete5 first" is... for example...

I will never recommend to do this... but...

1. Back up your existing database like using MyPHPAdmin
2. Erase all tables from your database
3. Install concrete5
4. Re-import other CMS's data onto your database using MyPHPAdmin

But again.. we don't want this to happen on your hosting server...

http://www.youtube.com/watch?v=lvpuT3aoypE...

If you install multiple CMSs onto your database... you may become the guy in the video... and will be kicked out from your server.

Again... there are plenty of other cheap hosting company out there which allows you to have multiple database tables. Why not switch?

I think they said it's not a top priority. They didn't say it's a bad thing but since even the cheapest hosts offer several databases, this never seemed to be very important..

That was my impression from other forum discussions...

Maybe I misunderstood them.

OK...

Since I own VPS... I didn't have any problem with this... But since the release of Japanese edition, I've getting complain about not having table prefix.

I explained here....

http://www.concrete5.org/community/features/database_table_prefix_d...

Many Japanese shared hosting company only let you have one database. And it may cost $40/mo to have multiple database.

Although that's may be the reason why their hosting tend to be fast...

Anyway, many Japanese users are accustomed to having table prefix due to the nature of Japanese hosting companies.

So I will start pushing a little more about having table prefix for my fellow Japanese users.....

Sorry for my changing mind.

Hi Katz,

Here are some reasons why I would like to have table name prefixes in Concrete5:

Our hosting company provides one MySQL database... I like this hosting company because they give me a shell prompt, and for 8 years they have provided reliable service and excellent tech support...

So we installed 4 CMS systems for testing and development use... generally speaking only one CMS gets used at a time... my business partner found Concrete5 to be very intuitive, so he built a simple website using Concrete5...

Now we want to dump the tables, but can't tell which ones go with Concrete5.

At this point, table name prefixes would _greatly_ simplify what I have to do to move the tables.

And no, I do not want to change hosting companies at this time.

Just my 2 cents worth...

Chuck

I just see one reason - your hosting partner support just a single database? Did I miss something?

Just to clarify this, no one ever said prefixes are bad. Problem is just the fact that 99% of all hosters support multiple databases.

It's therefore not a problem for the majority and therefore isn't important to most people.

If it would be important to me, I'd ask Andrew about the roadmap and start implementing it on my own. Problem with this is, I don't need prefixes and as long as no one who's willing to contribute some code has that problem, it won't change in the near future I guess..

It might be on the roadmap already, but this I can't tell you, because I know nothing about the roadmap (:

oooo ooo! Mr kotter.. I know that one!


Yeah we actually do think this is a bad idea because we think a bunch of people are going to start installing concrete5 in over taxed web spaces that are already running half a dozen different apps and then the forums will be filled up with people wondering why their concrete5 install is branded drupal..

that being said, it /is/ amazingly on our roadmap. we're gonna do this at the same time that we build better support for multiple databases. we want concrete5 to work with oracle, 'specially now that oracle owns mysql. oracle is a pain to build for, so we're gonna have to rename a bunch of tables at that point. that will be when we add prefixes, because as much as we think it will lead to sloppy installs, I agree with Remo - there's nothing about the prefix itself that is inherently evil..

when?

very likely not this year.

This is like listening to 'dumb and dumber' blowing smoke out their a##.

NONE of your arguments hold water when examined by common sense:

1) MOST hosting providers run dozens if not hundreds of databases from a single MySQL box... accessing a table within a database is probably more efficient than opening a new database on the server. By the logic of some here, each database should have it's own box!

2) SEE #1. MOST websites run on VIRTUAL hosts, not via dedicated server. So again, this whole argument of 'overload' is ignorant. You cannot design against user stupidity or ISP incompetence.

3) EVERY other CMS offers table prefixes as a basic feature. I don't see any complaints about bottlenecks due to table prefixing.

4) Telling users their hosting company is the problem "for only offering a single db" --and then suggesting they find a new provider-- is ignorant.

Here's my example:

My ISP gives me 5 unique IP's for 5 totally separate sites for $10 a month... if I want additional unique IP's, it's $0.50 (50 cents) per IP# for each extra website! THOSE OF YOU WHO KNOW SEO/GOOGLE understand the value of having a unique IP for individual websites.

I run 25 separate sites (each has its own IP#) with that provider. Their trade-off is: only one db per account, because my ISP just assumes table prefixes can be used for any CMS or eCommerce applications.

Tell me, where else can one get 25 unique IP's for $20 a month?!
So... NO, I'm not switching providers because Concrete5 screwed up.

The 'odd man out' is Concrete5 for not using table prefixes. LAME.

I'm sure glad I learned about this major flaw before installing Concrete5 and wrecking my ZenCart (with table prefixes) setup!

VERY disappointed, C5 -seemed- like the best CMS solution until now.

so instead of asking for it, I'm going to do it. Or at the very least attempt it.

I have a network of sites riding on this feature.

Here's my problem and why I need it:

Host doesn't allow db creation from scripts - they allow table creation, but not database. Dbs must be manually created from their web based control panel. Granted, I could automate a script that accesses the panel and creates a new db, but I find that to be an awful security risk.

Even if the result is lower performance, that's not a problem for this particular case.

I will report my work to ONLY Andrew and Frans as it progresses. So don't bug me about it. Just know that it in progress for v5.3.1.1 and be happy with that.

uhh, concrete5 doesn't automatically make a database either, we just create tables in one you define.

correct, a normal version of c5 doesn't create a database.

However, if I wanted to create a separate instance of c5 on the fly, I'd need a new DB or table prefixes.

Here's an example:
Client wants to run a collegiate sports network.http://uga.collegiate-sports-network.com... would need to be a completely separate instance than sayhttp://psu.collegiate-sports-network.com...

Why not combine them? Tell UGA fans and Florida Gator fans they need to work together. Negating the social implications, it would be much easier for site operators to have each school's files and content separated physically. No?

So if the container site has a package that allows the admin to create new versions of c5 on the fly from the dashboard this would be awesome.

Same issue here.

Prefix during install (like Wordpress) would be just nice.

Have a very different use case for table prefixes here:
Single Sign On.
I could have prefixOne_ and prefixTwo_ and equalize the salt and session value in site.php to the same on both setups, then add DB contraints to share a user-base.

Given that I can modify cookie creation to wildcard domains, I could then use one.site.com and two.site.com and wouldn't need to care about syning users on both sites anymore. That's what the contraints are for. DB functions could also solve that, but yeah this is the easies way I can imagine. Clear me up if you know a better SSO solution.