I set up two Wordpress blogs a while ago, both obviously having different databases. I've more recently merged these databases into one by changing the tables prefixes, therefore these two 'entities' have the same amount of tables and the same names (as they originate from a Wordpress install) but with different prefixes, i.e.:
Blog1_tabledata1
Blog1_tabledata2
Blog1_tabledata3
Blog1_tabledata4
Blog2_tabledata1
Blog2_tabledata2
Blog2_tabledata3
Blog2_tabledata4
I have now realised that I need to merge these two databases (where they're both using the same tables) so that they can be used in the same Wordpress instance (later separated by tags etc).
What would be the most simple way of doing this?
(Please note I am asking this from a MySQL standpoint - this is not a Wordpress question!)
If you absolutely are not looking for a wordpress solution, that means you are not looking at all domains. By this, I mean that you are not looking at what the data means. This could be a problem. but nevertheless:
figure out the foreign keys. If the tables are MyIsam instead of InnoDB, they will be implicit. Figure out what ID points to what field.
select from one DB and insert into the other. This mean you add the rows of one table to the equivalent of the target database. Auto-increment rows will be fine. But for foreign key (explicit AND implicit) fields here is were the trouble starts.
If you insert, say a user, the user gets a new ID -> You have to find the equivalent of the userid in the old db so you can insert the foreign keys with the right ID. this is tricky and without making this a wordpress-question there is no more help we can give you: just figure out what rows they should be :). it is database // domain specific. (with that I mean you can't just figure that out by looking at the fields, you must know some of what they mean)
If the db is correct, this should work, but I'm not sure if you get into trouble with duplicates (all should go on ID, and you fixed that in step 3 with unique and connected id's. but if your domain doesn't want two accounts, two pages or two whatevers (tags?) to have the same name, you still have a problem. But again, this is domain specific logic and you're specifically asking not to go there.
Related
When someone registers on my site they get variables in 3 different tables.
However, due to unknown reasons, the ID's for some tables are more pushed up than others.
So someone will register and get these ID's
Table 1 - ID 12
Table 2 - ID 15
Table 3 - ID 13
I utilise these ID's being the same for various table joins, every user that signs up I have to manually go in and change the ID's!
I'm not sure what to do, it's really tedious. Should I just wipe the databases and restart?
It sounds like all three of your tables are set to auto-increment, and you are trying to imply a foreign-key relationship between them using their primary keys. This can work in the short-term, but if records are manually inserted, or if you have a scenario where not all three tables have data inserted, it will throw things off. You can reset the auto increment value to whatever you'd like, but this is only a temporary fix.
If this is the case, you should identify which of these is really the "master" table in relation to the others. Then ask yourself, is it really necessary to split this data into three tables, when in fact it all relates 1:1? And finally, if it is necessary to do so, then a best-practice you should consider would be to declare separate fields in the child tables and define these as having explicit foreign-key relationships to the master table.
I've only just registered so I can't comment, but it would be helpful if you could show the "create table" SQL statements.
If you know what you are doing and really want it to work this way. Then you can set the Auto Increment value to a specific number, like this ALTER TABLE Persons AUTO_INCREMENT=100.
If you don't really know what you are doing. You better read more about using databases, primary keys, relationship tables and more.
I am editing a schema in MySQL workbench. I imported the schema from a mysqldump. Since it doesn't include any foreign keys, I am adding the relationships manually.
Here is my problem: When adding a relationship, workbench adds a column with the foreign key to one of the tables. However, the column is already present. I have to remove the current column and change the name of the new column to the name of the original column.
I illustrated it in the attached pictures:
The two original tables
The two tables after adding the relationship
After removing original column and renaming new column - this is what I want in one step
Is there a way to avoid this, and choose the target-column when adding the relationship, so that I don't have to edit a larger number of tables?
(Edited to add: The example tables are not the tables I want to connect, in case somebody recognizes the Drupal 8 tables - they were just short enough to aid as an example).
Most of the relationship commands automatically create columns to host the new relationship. However, there's one tool that allows to select existing columns for a 1:n relationship. See in the tools toolbar. The last icon contains a picker symbol. This is the one to use. For quick access simply press '6'.
I have a MySql database containing data about users of an application. This application is in production already, however improvements are added every day. The last improvement I've made changed the way data is collected and inserted into the database.
Just to be clearer, my database is composed of 5 tables containing user data and 1 table to relate all the tables, through foreign keys. These 5 foreign keys, together, form my Unique Index for this "Main Table" I have.
The issue is that one of these tables containing user data changed its format, and I want to remove all the data older than the modification I made on my application (just from this table, the other ones I need to keep untouched). However, this dataset has foreign keys in the main table, and I can't just drop these lines on the main table because the other informations I have are important. I tried to change the value of the foreign key for this table, in specific, but then, obviously, I have a problem related to duplicated indexes.
Reading on internet, I've found a solution to my problem using "Insert ... On duplicate key update ...", but i'm not inserting data, just updating it. I have an Idea about how to make a program on PHP to update my database, but is there another easier solution? Is it possible to avoid these problems using just MySql syntax?
might be worth looking at the below link
http://www.kavoir.com/2009/05/mysql-insert-if-doesnt-exist-otherwise-update-the-existing-row.html
I am working with a database where "almost" every table in the database has the same field and same value. For example, almost all tables have a field called GroupId and there is only one group id in the database now.
Benefits
All data is related to that field and can be identified by said field
When a new group is created data will be properly identified for the group
Disadvantages
All tables have the this field
All stored procedures need to have this field as a parameter
All queries have to filtered by this field
Is this a big deal? Is there an alternative to this approach?
Thanks
If you need to be able to identify data by more than one group in the future, having foreign keys is a good practice. However, that deosn't mean all tables need to have this field, only the ones directly related to the group. For instance a lookuptable with state values may not need it, but the customers table might. Adding it to all tables willy-nilly can lead to bad things when you try to delete a record and have to check 579 tables (only 25 of which are pertinent). All this depends greatly on what the meaning of the groups is. Most of our tables have a relationship to the client table, because they contain data related to specific clients and because we don't want various clients to have the ability to see data for other clients. Tables which do not contain that kind of data do not.
Yes most queries may need the field and many stored procs will want to have it as an input variable, but if you truly need to filter on this information, then that is as it should be.
If however there is only one group and will never be more than one group, it is a waste of time, effort and space.
I am using Mysql 5 and Ruby On Rails 2.3.1. I have some validations that occasionally fail to prevent duplicate items being saved to my database. Is it possible at the database level to restrict a duplicate entry to be created based on certain parameters?
I am saving emails to a database, and don't want to save a duplicate subject line, body, and sender address. Does anyone know how to impose such a limit on a DB through a migration?
You have a number of options to ensure a unique value set is inserted into your table. Lets consider 1) Push responsibility to the database engine or 2) your application's responsibilitiy.
Pushing responsibility to the database engine could entail the use of creating a UNIQUE index on your table. See MySql Create Index syntax. Note, this solution may result in an exception thrown in case a duplicate value is inserted. As you've identified what I infer to be three columns to determine uniqueness (subject line, body, and sender address) you'll create the index to include all three columns. Its been a while since I've worked with Rails so you may want to check the record count inserted as well.
If you desire to push this responsibility to your application software you'll need to contend with potential data insertion conflicts. That is, assume you have two users creating an email simultaneously (just work with me here) having the same subject line, body, and send address. Should your code simple query for any records consisting of the text (identical for both users in this example) both will return no records found and will proceed along merily inserting their emails which now violate your premise. So, you can address this with perhaps a table lock, or some other syncing field in the database to ensure duplicates don't appear. This latter approach could consist of another table with a single field indicating if someone is inserting a record or not, once completed it updates that record to state it has completed and then others can proceed.
While there you can have a separate architectural discussion on the implications of each alternative I'll leave that to a separate post. Hopefully this suffices in answering your question.
You should be able to add a unique index to any columns you want to be unique throughout the table.