I have an assignment where one of the questions is asking for an "extended SQL schema" of a given object-relational database. Does anyone have an idea of what this question means?
The given database tables are: car_parts, engine_parts, tires and windows.
I have come up with the following code to create the schema (which I am a bit shaky about too):
CREATE SCHEMA products;
CREATE TABLE products.car_parts OF car_parts_type;
CREATE TABLE products.engine_parts OF engine_parts_type;
CREATE TABLE products.tires OF tires_type;
CREATE TABLE products.windows OF windows_type;
Is there anything else I need to add to this schema to create an extended schema? Is this the correct way to go about making a schema?
I interpret "extended schema" to mean you have user-defined types involved - either custom table types or custom data types.
Related
I'm new to Azure and not great with SQL so any help would be greatly appreciated.
I have a Database where each user has a Schema. Each Schema has identically structured tables with the same name, say "Table".
I now require a View in another Schema which provides a read-only union of all the rows from all the tables Table.
I was successful in creating a Schema, say Views, handling its permissions and creating a View, "TableView", with the following SQL from Partitioned Views # learn.microsoft.com:
CREATE VIEW Views.TableView
AS
SELECT *
FROM Schema1.Table
UNION ALL
SELECT *
FROM Schema2.Table
UNION ALL
SELECT *
FROM Schema3.Table
...
GO
I now wish for this View to be dynamic as future Schemas (SchemaX) are added or even possibly removed without having to repeatedly DROP and CREATE TableView over and over.
Is it possible to create the View in such a way that it would automatically query all tables with the same name? Or perhaps there is some way to 'add' an additional table post creation?
I can get a list of all SchemaX.Table by querying INFORMATION_SCHEMA, but other than having a python script DROP and CREATE the View again I am lost.
Thanks
Thanks for #larnu's comments, it's very useful and professional:
To achieve this dynamically, it would be impossible to do in a VIEW.
You would have to use a stored procedure, and that means you can't do
simple things like SELECT from it, making it far harder to use.
Instead of having 17 tables, all identical, on different schemas you
have one table, with a column BusinessName. Instead of
MySmartCompany.Mytable you have a column in the table dbo.MyTable (or
your generic schema), called BusinessName which has the value 'MySmartCompany'.
This also can be beneficial to other community members.
I'm trying to create a table type which has a lot of fields, in SQLScript for a Hana machine.
I've tried some combinations of 'Like' and other keywords but it all comes out as a syntax error.
Furthermore, I could not find any hint of this in the SQLScript reference guide.
I've been creating tables LIKE [orignal table] with no data and inserting records into it - not practical :(
Thanks in advance.
Miguel
EDIT: to understand if the procedure 'get_object_definition' can be used with tables with case-sensitive names.
In this image we can see the procedure calls, with the error message; in the image after, the tables and table types in each of the schemas.
EDITED: I got it, have to call the procedure with ' " table_name " '
There is no specific command to create a type based on an existing table or another type.
What you can do is to get the definition of the table via
call get_object_definition ('<schema name>', '<table name>');
and edit the object creation statement to a CREATE TYPE statement. This is basically just changing the starting part of the statement and cutting away some parts at the end.
I have some questions about the schema in a table.
Sometime when you create a table the default schema is dbo.TableName. Is the dbo the default schema name? I believe you can change or specify the schema when creating a table right, because there are tables that have different schema like: Sales.Tablename or Users.Roles, etc. I believe the purpose of a schema is to make a difference between tables or something like that? Something like a namespace within a C# class. Is it possible to have two tables with same name but a different schema, like: Sales.Users, Marketing.Users ?
dbo is the default schema. You can change the default schema for each sql-login.
If you accidentally create a table in the wrong schema, you can move it:
-- Moving Peter table from Sales schema to Orders schema
ALTER SCHEMA Orders TRANSFER Sales.peter
You can specify which schema to create the table in by specifying it before the table name:
CREATE TABLE Sales.Users(id int);
One of the purposes of schemas is to create logical groups of tables, just like namespaces in C#. They are also useful for controlling permissions and more.
Yes, table names only need to be unique within each schema..
Sometime when you create a table the default schema is dbo.TableName. Is the dbo
the default schema name?
Why do you ask? It is quite obvious that dbo is the default schame name if you get it as default, or? On top it is the only usable schema a new database has.
I believe you can change or specify the schema when creating a table right,
What sense would multiple schemata have if you could not use them? And as the create table syntax clearly states you can specify a schema.
I believe the purpose of a schema is to make a difference between tables or
something like that? Something like a namespace within a C# class.
That pretty much sums it up.
Is it possible to have two tables with same name but a different schema,
What about you spend 10 seconds to try it out? Are you challenged by he concept of trying something totally simplistic out? And the answer is yes. object names have to be unique - within their schema.
I know databases aren't supported by CREATE SYNONYM, but I'm looking to achieve the functionality this would provide.
We've got Database A which contains views to tables on Database B. The trouble is "Database B" isn't always called "Database B". We use database projects for deployments, which at the moment fall over with an "Invalid Object Name" error if there isn't a "Database B".
The workaround at the moment is to open up the .dbschema file and do a find and replace. I guess another option would be to create a load of table synonyms.
What's the best way of changing the database a number of views reference without changing each view individually?
Thanks
Synonyms are a good way to do this. You have to create the synonyms at the object level though (as you've discovered). An easy way to do this would be to write a script that runs through the list of tables in DatabaseB (from your example) and creates a synonym for each one in DatabaseA. Keep the name of the synonym the same so the code in your views doesn't have to change. For instance, you you have tbl_a, tbl_b, and tbl_c in DatabaseB, you'd want your script to eventually do the following:
create synonym [otherDb].[tbl_a] for [DatabaseB].[schemaB].[tbl_a]
create synonym [otherDb].[tbl_b] for [DatabaseB].[schemaB].[tbl_b]
create synonym [otherDb].[tbl_c] for [DatabaseB].[schemaB].[tbl_c]
Now, in your view code, you'll always use [otherDb].[tbl_a], [otherDb].[tbl_b], and [otherDb].[tbl_c]. Hope this makes sense.
Last year I helped my current client with the implementation of a very similar design. We wrote a set of functions and stored procedures which generate the views automatically. Whenever you need to change the target database it generates the code to drop and recreate all of the views.
The code wasn't too difficult. It just uses the system tables to generate view code. I also wrote a Powershell prototype that uses SMO to do the same thing. The key is to have it automated to the point of requiring a single call so that you can do it easily and accurately.
We also included an exception table that used a pattern match of tables to exclude from view generation. It included a schema column and a table name column, each of which accepted LIKE patterns, so you could put "my_schema" and "%" to exclude all tables in the my_schema schema.
One master stored procedure accepted a target database name and would generate the entire script. Once the script is generated you can run it in SSMS or have that part automated as well.
This whole thing would be even easier if you just wanted to generate synonyms. We were using views so that we could change column lists, etc. and have the view DB look different than the target DB where needed.
We are thinking about to create new schema with its own 3 tables which will be created on the fly for an individual customer.
To run a particular query for those tables in a procedure, should we have something like this.
declare #sName nvarchar(200);
select #sName =Schema_Name from schema where Schema_Id = passed_id_from_code
ALTER USER UserName WITH DEFAULT_SCHEMA = #sName
-- Run the statements here --
...
-- After finishing executing statements
ALTER USER UserName WITH DEFAULT_SCHEMA = db;
In this scenario, can concurrent customers from various schema can update their own schema table or it will conflict.
Your suggestions are welcome.
Anil
Most SQL databases have each table create as an unique entity in that database. That means that each table can be modified and altered individually with no relation to the other tables. CUSTOMERA.TABLE_ONE is a different object in the database that CUSTOMERB.TABLE_ONE. They do share the same name, but they are not the same object with potentially different layouts (as they have different schemas).
So unless there is some restriction on the RDBMS you can do this. Now having different schemas for each user may not be good. If you are develop the same app to handle several customers, you have to make sure it will work with all schemas and all custoemrs. In potentially different versions of the schema.
If you are going for a multi-tenant architecture, it may be wiser to use some kind of extension to to table. So you have a single DB.TABLE_ONE, with a CUSTOMER_DATA column where you put data in a know and flexible format (say JSON or XML). Some RDBMS have that that as a native features (I believe DB2 is one of them).
Hope this helps.