I am creating abstraction of database schema using object oriented programming. I have a design issue: should indices be top-level objects (like tables, view, stored procedures) or rather should be accessible through a table, like columns? What about triggers too?
I am building a python package (http://code.google.com/p/fathom/) for database schema discovery. Right now indices are accessed through table, but I see that some tools for administering database have indices as separate entry in some tree view, just like tables. That's why I am wondering, If I am doing it right.
"Indices" are part of a single table like "columns", they are not independent, like a S.P. where the developer can alter o modify several tables.
They are composed by several columns or expressions from a single table.
In the other hand, I agree sometimes its confusing. Many tools put relations among tables as dependant on a single table, and I prefer to think relations as an item of the database, not as a single table, just the opposite of "indices".
Related
I'm dealing with a huge ERP database, hundreds of tables, and am having trouble figuring out how one entity is referenced from another. Let's call them the "sale" table and the "shipment" table. Each has FK relationships with numerous other tables, but no FK links either one to the other, and no obvious associative table is linked to both.
Is there any good way using SQL or the psql command line to discover the chains of relationships that connect the two tables?
Is there any good way to discover the chains that connect a specific row or PK of "sale" and a specific row/PK of "shipment"?
You should look at a tool like schemacrawler. It's good a opensource tool for data modelling retro-engineering.
You can find documentation here.
I have shared resources across all of my databases. Users, Companies etc. These are shared between all of my databases and the tables are the same. I want to create on Database for these tables and have all of my databases reference this one instead of having multiple tables that are the same. I come from a C# background and I am not very proficient in SQL. I am writing a new application that uses several of the databases we have.
Question: Should I make one database an authoritative source on these resources? The problem I see is I need Foreign Key relationships between databases and without triggers this is not possible. Not to mention when I write my linq statements I cannot query by these items.
We were able to achieve this by having one central database as the source of truth, then having copies of the applicable tables moved out to all the databases that needed it via triggers. You have to make sure all CRUD is done to the source of truth database, otherwise it gets very complicated to manage everything. You can then create the foreign keys to the copy tables.
I was wondering if there was a way (relatively simple I hope) to get information about the table and its attributes and realtionships?
Clarification: I want to grab all tables in the database and get the meta-model for the whole database, tables, column data, indicies, unique constraints, relationships between tables etc.
The system has a data dictionary in sys.tables, sys.columns, sys.indexes and various other tables. You can query these tables to get metadata about the database structure. This posting has a script I wrote a few years ago to reverse engineer a database schema. If you take a look at it you can see some examples of how to use the system data dictionary tables.
there are a whole bunch of system views in the information_schema schema in sql server 2005+. is there anything in particular you're wanting?
some of those views include:
check_contraints,
columns,
tables,
views
Try sp_help <tablename>. This will show you foreign key refrences and data about the columns, etc - that is, if you are interested in a specific table, as your question seemed to indicate.
If using .NET code is an option SMO is the best way to do it.
It abstracts away all these system views and tables hiding them behind nice and easy to use classes and collections.
http://msdn.microsoft.com/en-us/library/ms162169.aspx
This is the same infrastructure SQL Server Management Studio uses itself. It even supports scripting.
Abstraction comes at a cost though so you need maximum performance you'd still have to use system views and custom SQL.
You can try to use this library db-meta
I was thinking of putting staging tables and stored procedures that update those tables into their own schema. Such that when importing data from SomeTable to the datawarehouse, I would run a Initial.StageSomeTable procedure which would insert the data into the Initial.SomeTable table. This way all the procs and tables dealing with the Initial staging are grouped together. Then I'd have a Validation schema for that stage of the ETL, etc.
This seems cleaner than trying to uniquely name all these very similar tables, since each table will have multiple instances of itself throughout the staging process.
Question: Is using a user schema to group tables/procs/views together an appropriate use of user schemas in MS SQL Server? Or are user schemas supposed to be used for security, such as grouping permissions together for objects?
This is actually a recommended practice. Take a look at the Microsoft Business Intelligence ETL Design Practices from the Project Real. You will find (download doc from the first link) that they use quite a few schemata to group and identify objects in the warehouse.
In addition to dbo and etl, they also use admin, audit, part, olap and a few more.
I think it's appropriate enough, it doesn't really matter, you could use another database if you liked which is actually what we do.
I'm not sure why you would want a validation schema though, what are you going to do there?
Both the reasons you list (purpose/intent, security) are valid reasons to use schemas. Once you start using them, you should always specify schema when referencing an object (although I'm lazy and never specify dbo).
One trick we use is to have the same-named table in each of several schemas, combined with table partitioning (available in SQL 2005 and up). Load the data in first schema, then when it's validated "swap" the partition into dbo--after swapping the dbo partition into a "dumpster" schema copy of the table. Net Production downtime is measured in seconds, and it's all carefully wrapped in a declared transaction.
I was reading about ORMs and one of the descriptions I read said that the ORM interacts with database metadata.
Why is this important or relevant?
Metadata, as I understand, is just a way of describing what the database contains. So, for example, the database might have an internal table that lists what user tables have been created. Why would something like this be useful to an ORM?
What this means is that the ORM maps the schema, or structure, of the database to objects. Typically, this means mapping tables to classes (User table to User class), fields to attributes (Age field to User.Age attribute), and each record then represents an instance of that object.
The ORM uses the metadata to generate the code used to access the tables. For example, if it's a date column then it generates the code to deal with that column as a date.
It will read foreign keys and primary keys to build relationships in the code as well as for generating the proper SQL syntax.
This is just a few of the ways it uses the metadata.