oracle
In schema A I created a table called "apples" with data.
In Schema B I created a copy of table "apples" from schema 1 using
create table apples as select * from schemaA.apples
My question is, now that I have schema B up and running. Can I drop/delete my schemaA.apples? There is no direct link between the tables correct?
Or if I drop schemaA.apples will schemaB.apples get runied?
There is no direct link between the tables correct?
Correct. You have two different tables, that are not related. You just copied data from one table to another at a given point in time.
Or if I drop schemaA.apples will schemaB.apples get runied?
No, there is no risk that it will impact the other table. Again, data was copied, and tables are independent.
Side note: the create table ... as select ... syntax (aka CTAS) just copies the data and the structure, but not the related objects like primary keys, constraints, indexes, sequences. You might want to check these objects, and recreate them too to the new schema.
I have lots of sql tables. The tables are "dependent" , i.e. constraints on foreign keys are defined between the tables.
I need to transfer the tables from sql to csv. What is correct way to do that:
Define tables exactly as they are defined in sql? (What should I do with the foreign keys?)
Try to generate other tables by joining the existing ones based on foreign keys in order to hide the foreign keys dependencies?
May be there are other options? What are the pros and cons ?
Thanks,
Note:This is need for another application that run some anylitics on the data
I would suggest to create a view in SQL which contains all information from all tables you need in your CSV later.
The view already implements the dependencies (link of two rows from different tables) and linkes all together in one table.
It would be way easier than your second proposal to create a new table because the view will do all the work for you.
I guess you will need your dependencies.
So you should not ignore them.
Here a quick example how they work:
Lets say you have 2 Tables the first one is named persons and the second one is cars. In the persons table you have 3 columns: ID, Name, Age. In the second one you have ID, Car. To see which person has which car you just check which id from the first table has which value for car in the second one.
If you link them together in a view the result is one single table with the columns ID, Person, Age, Car.
Same does the view.
Later you can simply export the view to CSV.
Maybe I can help you better if you define your needs a bit more detailed.
What kind of data is in your tables, how are they linked(what are the primary/secondary keys).
The only way I can think of doing it, since what I want to do is have a database of all the companies, and their respective information, then have another database per each company that sorts their orders and jobs, Is there a cleaner way than creating a table for each element in the company list table? If not, how would I go about doing this?
create trigger on yourdb for insert
then inside the trigger
create table and insert int it the specific row
Your question is a bit confusing. It seems that you may want to add the company id as a key on all the relations that exist. This would allow you to keep various company information in the same table structure and select from it by filtering on the company id.
So there was this VIEW in oracle named XYZ and somebody says, we are going to replace it with a TABLE of the same name.
What kind of an impact can this create to existing SQL's written on that view?
Is the syntax for querying a VIEW same as that for a TABLE?
By "... replace it with a table ..." I assume you mean that a table is created with the same data the view was referencing. In other words, the new table redundantly contains data from other tables (those that the view was referencing).
SELECT-Statements will not need to be changed - the syntax is the same.
BUT: The view will immediately reflect changes in underlying tables. The table obviously not - it will have to be kept in sync by triggers or application logic. So depending on the view, this might be a rather big change. Even more so if the view was updateable.
Example:
Suppose the view was defined as ... select a.key, b.name from a,b where b.key = a.b_ref
Then selecting from the view will always reflect changes to tables a and b.
If you replace it by a table, you would have to update that new table every time you update table a or b.
As long as the columns are identical in Name DataType and DataLength, then there will be no impact.
SQL SELECT statments essential treat VIEWS and TABLE as the same things.
Is there any way to use inheritance in database (Specifically in SQL Server 2005)?
Suppose I have few field like CreatedOn, CreatedBy which I want to add on all of my entities. I looking for an alternative way instead of adding these fields to every table.
There is no such thing as inheritance between tables in SQL Server 2005, and as noted by the others, you can get as far as getting help adding the necessary columns to the tables when you create them, but it won't be inheritance as you know it.
Think of it more like a template for your source code files.
As GateKiller mentions, you can create a table containing the shared data and reference it with a foreign key, but you'll either have to have audit hooks, triggers, or do the update manually.
Bottom line: Manual work.
PostgreSQL has this feature. Just add this to the end of your table definition:
INHERITS FROM (tablename[, othertable...])
The child table will have all the columns of its parent, and changes to the parent table will change the child. Also, everything in the child table will come up in queries to the parent table (by default). Unfortunately indices don't cross the parent/child border, which also means you can't make sure that certain columns are unique across both the parent and child.
As far as I know, it's not a feature used very often.
You could create a template in the template pane in Management Studio. And then use that template every time you want to create a new table.
Failing that, you could store the CreatedOn and CreatedBy fields in an Audit trail table referencing the original table and id.
Failing that, do it manually.
You could use a data modeling tool such as ER/Studio or ERWin. Both tools have domain columns where you can define a column template that you can apply to any table. When the domain changes so do the associated columns. ER/Studio also has trigger templates that you can build and apply to any table. This is how we update our LastUpdatedBy and LastUpdatedDate columns without having to build and maintain hundreds of trigger scripts.
If you do create an audit table you would have one row for every row in every table that uses the audit table. That could get messy. In my opinion, you're better off putting the audit columns in every table. You also may want to put a timestamp column in all of your tables. You never know when concurrency becomes a problem. Our DB audit columns that we put in every table are: CreatedDt, LastUpdatedBy, LastUpdatedDt and Timestamp.
Hope this helps.
We have a SProc that adds audit columns to a given table, and (optionally) creates a history table and associated triggers to track changes to a value. Unfortunately, company policy means I can't share, but it really isn't difficult to achieve.
If you are using GUIDs you could create a CreateHistory table with columns GUID, CreatedOn, CreatedBy. For populating the table you would still have to create a trigger for every table or handle it in the application logic.
You do NOT want to use inheritance to do this! When table B, C and D inherits from table A, that means that querying table A will give you records from B, C and D. Now consider...
DELETE FROM a;
Instead of inheritance, use LIKE instead...
CREATE TABLE blah (
blah_id serial PRIMARY KEY
, something text NOT NULL
, LIKE template_table INCLUDING DEFALUTS
);
Ramesh - I would implement this using supertype and subtype relationships in my E-R model. There are a few different physical options you have of implementing the relationships as well.
in O-R mapping, inheritance maps to a parent table where the parent and child tables use the same identifier
for example
create table Object (
Id int NOT NULL --primary key, auto-increment
Name varchar(32)
)
create table SubObject (
Id int NOT NULL --primary key and also foreign key to Object
Description varchar(32)
)
SubObject has a foreign-key relationship to Object. when you create a SubObject row, you must first create an Object row and use the Id in both rows