I am new to SQL Server. On the previous job I used working with Postgres and MySQL. But now I was faced with the task connected with SQL Server. And I discovered very strange thing in the DB with that I should work. There don't exist any relations!
Is it normal to SQL Server? How can I automatically connect tables according to their primary keys? Any other ideas?
An screenshot of the ER diagram:
Unless you are talking about creating hundreds of FKs you may be better off by just adding those relationships manually either through SSMS database diagram or through a sql script.
If the number of possible relations is really large or you expect to have to do this again in the future, you may want to look to SMO (SQL Management Objects) and either use Powershell or a small C# program to script out the tsql that would join those tables. But you would need to make sure that there is a repeatable pattern / naming convention between the columns and tables that you can leverage. For Example:
Table1
ID
Name
Table2
ID
Table1ID
Name
Here you could consider Table1ID as a FK referencing Table1.ID
Related
I have two databases, one is on SQL Server and the other is on PostgreSQL. Is there a way to join tables from these two database, or, if not possible, is there a way to pull from both databases and put the result in a temp table?
Thanks!
Foreign Data Wrapper
PostgreSQL supports Foreign Data Wrappers, per the SQL standard. See the wiki.
The easy way, use FDW for SQL Server and see remote SQL Server table like a local table.
You could create link server, see below link for more details:
https://learn.microsoft.com/en-us/sql/relational-databases/linked-servers/create-linked-servers-sql-server-database-engine?view=sql-server-ver15
I want a simple way to find all the Foreign Keys of my table.
For example having a table Customers, I want to find the tables with a relationship to this table, I use to find relationships using the Diagram but it is too slow.
Desired result = Customers_Accounts, Customers_Cities, Customers_Properites, etc
Yes just select your table and press ALT + F1, at the bottom of the result set you will see all the references
The reason that the dependencies is slow is due to the number and complexity of queries that sql sever runs in order to show you a nice hierarchical structure.
There are some ways to get the data you need which vary depending on the version of sql and how much info you are looking for.
Taken from Microsoft Docs - View the Dependencies of a Table
USE AdventureWorks2012;
GO
SELECT * FROM sys.sql_expression_dependencies
WHERE referencing_id = OBJECT_ID(N'Production.vProductAndDescription');
GO
Obviously you'll need to change the AdventureWorks2012 to your database and Production.vProductAndDescription to your Customer schema and table name.
The above works for the latest sql server editions, for older editions you may need to refer to the following links:
MSSQL Tips - Different Ways to Find SQL Server Object Dependencies
MSSQL Tips - Listing SQL Server Object Dependencies
If I have SQL tables tblA and tblB and they have one to many relationship between them.. can we create multiple raven db documents automatically .. Can I automatically load documents in Raven DB... from SQL server tables any other way... using any tool?
There is a ETL demo in Raven's code base.
Additionally, you may have a look at how Raccoon imports a SQL database for Subtext into RavenDB.
In the SQL Server 2005 books online section "Defining Named Queries in a Data Source View (Analysis Services)", it states:
A named query can also be used to join multiple database tables from one or more data sources into a single data source view table.
Does anyone know where I can find examples or tutorials on how this can be done?
EDIT: To provide some additional background...
I am working with an analysis services project in the SQL Server Business Intelligence Development Studio for SQL Server 2005. I have defined a data source for each of my databases which are on different servers. I am trying to create a named query which will be a union of a table from each data source. The problem is that the named query requires me to choose a single data source for the query. The query is executed against this data source which does not know anything about the data sources in my project. However, according to the SQL Server 2005 books online, what I am trying to accomplish should be possible based on my quote from above.
MSDN has this link describing Named Queries and this link walking you through the process of creating one.
Edit: I think that to use multiple datasources, you would need to fully qualify your table to hit other datasources when creating your query, like this:
SELECT user_id, first_name, 'DB1' as DB FROM users
UNION
SELECT user_id, first_name, 'DB2' as DB FROM Database2Name.dbo.users
to get results like
user_id first_name DB
1 Bob DB1
2 Joe DB1
11 Greg DB2
12 Mark DB2
If by "multiple data sources" you mean multiple databases, then you can do this if you fully qualify the database name.
For example if I have two databases I can do this:
SELECT * FROM DatabaseA.dbo.SomeTable
JOIN DatabaseB.dbo.OtherTable
ON DatabaseA.dbo.SomeTable.Id = DatabaseB.dbo.OtherTable.Id
Make sure that you don't forget the dbo bit (the owner), otherwise it won't work.
The only other sort of "multiple data sources" that I'm aware of is distributed queries which allows you to perform queries over multiple remote instances of sql server:
sp_addlinkedserver 'server\instance'
SELECT * FROM [server\instance].DatabaseA.dbo.SomeTable
JOIN DatabaseB.dbo.OtherTable
ON [server\instance].DatabaseA.dbo.SomeTable.Id = DatabaseB.dbo.OtherTable.Id
We have an MS Access database that we want to migrate to a SQL Server Database with a new DB design. A part of the application that uses the SQL Server DB is already written.
I looked around to find out how to do the migration step most easily and started with Microsofts SQL Server Integration Services (SSIS). Now I have gotten to the point that I want to split a table vertically for normalization reasons.
A made up example looks like this
MS Access table person
ID
Name
Street
SQL Server table person
id
name
SQL Server table address
id
person_id
street
How can I complete this task best with SSIS? The id columns are identity (autoincrement) columns, so I cannot insert the old ID. How can I put the correct person_id foreign key in the address table?
There might even be a table which has to be broken up into three tables, where a row in table2 belongs to table1 and a row in table3 belongs to a row table2.
Is SSIS the appropriate means for this?
EDIT
Although this is a one-time migration, we need to have an automated and repeatable process, because the production database is under heavy usage and we are working on the migration in our development environment with recent, but not up-to-date data. We plan for one test run of the migration and have the customer review the behaviour. If everything is fine, we will go for the real migration.
Most of the given solutions include lots of manual steps and are thus not appropriate.
Use the execute SQL Task and write the statement yourself.
For the parent table do Select into table from table... then do the same for the rest as you progress. Make sure you set identity insert to ON for the parent table and reuse your old ID's. That will help you keep your data integrity.
For migrating your Access tables into SQL Server, use SSMA, not the Upsizing Wizard from Access.
You'll get a lot more tools at your disposal.
You can then break up your tables one by one from within SQL Server.
I'm not sure if there are any tools that can help you split your tables automatically, at least I couldn't find any, but it's not too difficult to do manually although how much work is required depends on how you used the original tables in your VBA code and forms in the first place.
A side note
Regarding normalization, don't go overboard with it: I know your example was just that but normalizing customer addresses is not always (rarely?) needed.
How many addresses can a person have?
If you count a home address, business address, delivery address, billing address, that's probably the most you'll ever need.
In that case, it's better to just keep them in the same table. Normalizing that data will just require more work to recombine and offers no benefit.
Of course, there are cases where it would make sense to normalise but I've seen people going overboard with the notion (I've been guilty of it as well) and then find themselves struggling to build more complex queries to join all that split data, making development and maintenance harder and often suffering a performance penalty in the process.
Access is so user-friendly, why not normalize your tables in Access, and then upsize the finished structure from there?
I found a different solution which was not mentioned yet and allows us to use all the comfort and options of the dataflow task:
If the destination database is on a local SQL Server, you can use a dataflow task with SQL Server destination instead of an OLE DB destination.
For a SQL Server destination you can mark the "keep identities" option. (I do not know if the english names are correct, because we have a german version.) With this you can write into identity columns
We found that we cannot use the old primary keys everywhere, because we have some tables that take a union of records from multiple tables.
We start the process by building a temporary mapping table with columns
new_id (identity)
old_id (int)
old_tablename (string)
We first fill in all the old_id s for every table that is referenced by a foreign key in the new schema. The new_id values are generated automatically by SQL Server.
So we can use a join to translate from old_id to new_id where needed. We use the new_id values to fill the identity (primary key) columns in the new tables with the "keep identities" option and can simply look them up in our mapping table for the foreign keys by a join.
You might also look at Jamie Thomson's SSIS Normalizer component. I just found out about it today (haven't actually tried it yet). The example he posts looks a lot like the one in your question.