I recently upgraded my website from Drupal 6 to Drupal 7. The number of tables in my MySQL database jumped from 135 tables to 283 tables. I may be wrong, but it seems to me that some of the tables are redundant copies left over from Drupal 6 (e.g., CCK fields now handled by Drupal 7 fields). Could/should I "clean up" the database by deleting the unused tables? How would I know which ones are safe to delete?
I believe that you should delete this tables if you know which ones are safe. )
Don't forget to make backup of your database.
I guess it is difficult to say which table belongs to which version of drupal. Make backup of your database and try to guess the tables to delete.
Related
I'm absolute new to databases! I've developed a web-app with a postgres database. For evaluating my software, I've done a first field experiment with a fee colleagues. Afterwards there was a lot of bugfixes.
Now I've got a dump after the field experiment. But then I changed my database, renamed two tables, added a few tables and so on. How can I merge my dumped/old database the easy way?
Is there an easy way?
Feel free to ask for some data or everything, that helps.
Greetings,
Tobias
Till now I am working in a project with Oracle database with lot of query,procedure,functions,sequences.But Oracle license term is going to finished.
So as per requirement project need to migrate from oracle to PostgreSQL.So my question is what are those important factors(functions/predefined tables etc...) are going to give me problem or I need to put special attention.
And how to check for performance issues ?
I am on DNN 4.7.0. I would like to delete all users who are in one of my custom roles and add new ones. Is there a way I can do this without deleting and adding users one by one? Are these users saved somewhere in the database where I could just run delete and insert statements?
Your help will be highly appreciated.
The User/Role Relationship is in the UserRoles table. You could write SQL against that table to insert the new relationship, and remove the old.
On a side note: I would highly encourage you to check out a newer version of DNN 4.7 is rather dated, buggy, and has security issues.
I am currently using Magento version 1.4.0.0. For different clients, when I install this same version of Magento, I get different number of tables in database of each of the clients.
I think the normal total number of tables is 267, but this prediction may be incorrect. Please correct my statement or mention, regarding the default number of database tables that should get installed for Magento CE version 1.4.0.0.
However, sometimes I get 258 number of tables, sometimes 260 & sometimes 265. It has become a great pain area for me, understanding about the correct number of database tables which should get installed by default. Can somebody please tell me why this is happening for Magento CE version 1.4.0.0?
Any help is greatly appreciated.
Edit:-
I often find the Bundle Products related tables or the tables with a suffix of "_idx" missing quite a times.
If Magento database structure of the number of tables depend upon the catalog usage (say of Bundle / Configurable / Grouped), then it will be very much error-prone to every administrator & will be creating more ambiguities to them, for configuring / creating the catalog products.
Magento creates temporary tables for a number of reasons, including re-indexing actions and how your site is configured (e.g. flat catalog, etc). Can you be more specific about which "extra" tables you are seeing? They're likely to be either temporary tables or caching/index tables.
Thanks,
Joe
I have a question but I'm not sure of the word to use.
My problem: I have an application using a database to stock information. The database can ben in access (local) or in a server (SQL Server or Oracle). We support these 3 kind of database. We want to give the possibility to the user to do what I think we can call versioning.
Let me explain : We have a database 1. This is the master. We want to be able to create a database 2 that will be the same thing as database 1 but we can give it to someone else.
They each work on each other side, adding, modifying and deleting records on this very complex database. After that, we want the database 1 to include the change from database 2, but with the possibility to dismiss some of the change.
For you information, ou application is already multiuser so why don't we just use this multi-user and forget about this versionning? It's because sometimes, we need to give a copy of the database to another company on another site and they can't connect on our server. They work on their side and then, we want to merge.
Is there anyone here with experience with this type of requirement? We have a lot of ideas but most of them require a LOT of work, massive modification to the database or to the existing queries.
This is a 2 millions and growing C++ app, so rewriting it is not possible!
Thanks for any ideas that you may give us!
J-F
The term you are looking for is Database Replication. You can google that to get more information about the topic (my personal experience is limited).
This was already done by ical (an old SunOS calendar app).
What you store/remember/transmit when the app makes the changes is not just the database contents, but the actual change log (e.g. "delete record with ID 1", "update record with ID 2 with these fields", "insert record with these fields")
That way you can apply these changes to master DB later on, AND to filter them before applying