Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
Assume I created updatable view:
CREATE VIEW OFFICEINFO AS
SELECT OFFICE, CITY, REGION
FROM OFFICES
Questions:
Will my OFFICEINFO reflect changes if I insert new value to
OFFICES?
How does synchronization work. Is there any predefined triggers on OFFICES table?
Can I switch off synchronization?
What is "pro" and "contro" of having synchronization between view and table?
For an oracle DB, a quick glimpse:
Yes
No triggers, you can imagine a view as a pointer to a table. It reflects the table data in real time, it just store the query
No, but you can use a materialized view as alternative.
Pro: you can use the view as an aggregator from table data (or tables if you use a join) ,it does not occupy space in database, con: if you change table/s structure the view will become invalid until recompilation.
You seem confused about views. A view is just a bunch of SQL code that gets plugged into a query when it runs. The closest equivalent in traditional programming languages is a macro.
So, the view doesn't really exist as a separate entity (with an exception noted below). Each time the view is referenced, the code that defines the view is inserted into the query. Hence a view always shows the latest changes to a table, without using triggers or other mechanisms.
The one exception is materialized views. Not all databases support these. But those that do allow the view to be instantiated as a table. The database itself takes care of synchronization. Your question is not about materialized views. They can be very useful in some circumstances.
I Hope you are working on SQL
Yes. View is just a pre-complied query
(Yes- Partially) .Synchroniztion you have to check manually. If you any operations like (CRUD) with view then Trigger with the Table will intiates
No. The view you have created never support for synchronization.
Synchronization would be fine to get the latest structure(Schema Level) or else it will leads to mismatched Schema in your View.
I can suggest you to read this for better understanding.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I'm creating a a workout app for a local gym, but I'm having a difficult time figuring out how to populate the workouts and exercises tables.
Right now, I have a 'Add Workout' button that displays a modal. and once the modal appears, you may begin adding exercises with additional weight and reps columns. But I don't understand how to properly insert/update these tables if I'm creating the workout/adding exercises all inside one form essentially.
My gut says the initial 'Add Workout' button performs an insert query and returns the id of the workout, so the exercises that are added can reference this workout, but I'm not 100% sure. Can anyone confirm this or provide some insight into how should be configured? Any help is greatly appreciated.
Personally, it seems like it's open to a lot of duplication to have Exercises created under a Workout when logistically, Exercises exist and sometimes are part of a Workout, and sometimes not. This would free up your Exercises to exist within multiple Workouts without recreating them.
I think stepping back for a moment to design this with paper and pen would be a good start. Write out the logic you think should happen when you Add Exercise, or Add Workout; how do you store them? How do you connect them?
A table of Exercises, with whatever goes under them.
A table of Workouts, which then have a list or multiple rows of exerciseID.
Then when you go to Add Workout, you create a new Workout and give it a name; hit Save; grab that workoutID, and ask the user "Want to add some Exercises?", which then allows the user to select the Exercises & # of reps or weight or time, etc... Based on the DB and UI, you may be able to retrieve the last created ID automatically with something like SCOPE_IDENTITY(), or you could have a trigger that returns the newest ID with that WorkoutName back to the calling statement; maybe even add a check against the CreatedBy username if concurrency is a concern.
Having a UI is nice, but from a design perspective, you really need to have a plan of attack on the data layout, logic flow, and all dependent connections before you create a UI to lay on top of it.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 4 years ago.
Improve this question
I'm trying to create a non-clustered index on a system base table sys.sysschobjs and get this error :
Index cannot be created on object 'sys.sysschobjs' because the object is not a user table or view.
I tried with DAC and with single-user-mode as well
Is there a way to create indexes on system base tables ?
Thanks,
To Sean's point, no, you cannot create indexes on system tables or system views.
Update 1: Because Microsoft says so:
https://learn.microsoft.com/en-us/sql/relational-databases/databases/master-database
https://learn.microsoft.com/en-us/sql/relational-databases/system-tables/system-base-tables
The idea is that the system databases, like master, are required in order for SQL Server to start. As a result, users are prohibited from making changes to these system objects that MS's developers have built in order to prevent users from blowing up the server. Microsoft doesn't explicitly say this, but it seems evident in the restrictions that they list on their site.
If you are questioning the performance of the system databases then you might want to check the following link for creating a maintenance plan:
https://learn.microsoft.com/en-us/sql/relational-databases/maintenance-plans/use-the-maintenance-plan-wizard
You can also run DBCC CHECKDB(master) to review the health of the database. For more information on how DBCC CHECKDB() works, see the following (it was written by the person who created the function):
https://www.sqlskills.com/blogs/paul/checkdb-from-every-angle-complete-description-of-all-checkdb-stages/
Update 2 - Final point:
Read the two purple Important bubbles on the page: https://learn.microsoft.com/en-us/sql/relational-databases/system-tables/system-base-tables
1.) The system base tables are used only within the SQL Server Database Engine and are not for general customer use. They are subject to change and compatibility is not guaranteed.
2.) Access to system base tables by using DAC is designed only for Microsoft personnel, and it is not a supported customer scenario.
This should resolve your question.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
What are the different approaches taken by vendors when implementing partitioning in a database?
This is response to marc_s's comment here: Does partitioning in mysql create tables or merely virtual tables?
Answers in the form of a link to a good book accepted :)
I can only speak about SQL Server:
Every partition is a new b-tree internally. The query processor creates the illusion to have one gigantic table. It has little optimizations which take into account that the table is partitioned because the partitioning itself is largely transparent to the optimizer: A partitioned table on column P with clustered index on (A, B) appears (performance wise) as a single table having the clustering key (P, A, B). This is true for seeks and scans.
Having partitions be a new internal table makes bulk operations on whole partitions easy: just drop the partition or create a new one. You can even swap partitions with unrelated tables if the schema is exactly identical! (ALTER TABLE SWITCH PARTITION)
Having partitions be b-trees has implications for maintenance: You can place individual partitions on different drives, or make them read-only and exclude them from backups.
You can mimic partitioning by using:
a set of tables named with some pattern as partitions;
a view on top of them to hide the structure of the data storage and present it as a single relation;
application integrated logic: make application aware bout the partitioning model and thus using the right tables to perform DDL statements.
This approach had been in use with ORACLE 7.2 (I might be wrong bout the version, too many years) and can be implemented in any database that supports views. If views are not there, you can create a special function/class within application that will mimic view behavior.
Still, it is quite complicated and error-prone approach as storage layout is visible outside the database. So, if possible, go for a native or isolated partitioning.
ORACLE supports partitioning on the database level as of 8th version, making storage layout completely hidden outside the database.
Although PostgreSQL has no built-in partitioning support yet, this is a work in progress now. Also, PostgreSQL already has a set of useful features that make it possible to make database-only partitioning, hiding implementation from any external users. You can check details here.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Why is database view used?
Since I always can use Select statement from original tables instead of creating a view and using select from it, I wonder what are benefits of using view in database?
It simplifies calls and provides a layer of indirection.
So, if you have a complex select with lots of joins, you can implement it in a view and simply call the view without need to consider all these joins. You can then reuse this view.
Additionally, if you use a view instead of a table in this manner, in the future if you need to migrate a column, you can easily do that and only require changes to the view.
There are several, but I think the main benefit is that views are the SQL implementation of logical data independence.
Build an updatable view, and applications that use the view are relatively immune to changes in the underlying tables. Change the structure of the underlying tables, update the view definition, and all applications work as if nothing had happened. (On legacy databases, there might be hundreds of applications written in dozens of languages. This is the big win.)
Other benefits (paraphrasing Chris Date)
"Automatic" security for hidden data. Restrict access to views, and you have fine-grained control over who sees what.
"DRY" capability for applications. A view can provide a simple, public interface to a complex SELECT statement, so applications can just SELECT column-list FROM my-easy-view.
Different users can see the same data in different ways.
Besides the obvious benefits that Oded mentioned, you can sometimes drastically improve speed by using materialized views. From wikipedia:
In a database management system following the relational model, a view is a virtual table representing the result of a database query. Whenever an ordinary view's table is queried or updated, the DBMS converts these into queries or updates against the underlying base tables. A materialized view takes a different approach in which the query result is cached as a concrete table that may be updated from the original base tables from time to time.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
Here's my situation. I've noticed that code gets harder to maintain when you keep embedding queries in every function that will use them. Some queries tend to grow very fast and tend to lose readability after concatenating every line. Another issue that comes with all of the concatenation is when you must test a specific query and paste it. You are forced to remove all of the " that held your query string together.
So my question is, what methods are being used to separate queries from the code? I have tried searching but it doesn't look like it's the right thing because i'm not finding anything relevant.
I'd like to note that views and stored procedure are not possible since my queries fetch data from a production database.
Thank you.
If you follow an MVC pattern, then your queries should be all in the model - i.e. the objects representing actual data.
If not, then you could just put all your repetitive queries in script files, including only those needed in each request.
However, concatenating and that kind of stuff is hard to get rid of; that's why programmers exist :)
These two words will be your best friend: Stored Procedure
I avoid this problem by wrapping queries in classes that represent the entities stored in the table. So the accounts table has an Account object. It'll have an insert/update/delete query.
I've seen places where the query is stored in a file and templates are used to replace parts of the query.
Java had something called SQLJ - don't know if it ever took off.
LINQ might provide some way around this as an issue too.
Risking being accused of not answering the question, my suggestion to you would be simply don't. Use an O/RM of your choice and you'll see this problem disappear in no time.
I usually create a data class that represents the data requirements for objects that are represented in the database. So if I have a customer class, then I create a customerData class as well that houses all the data access logic in them. This keeps data logic out of your entity classes. You would add all you CRUD methods here as well as custom data methods.
Youc an also use Stored Proceedures or an ORM tool depending on your language.
The main key is to get your data logic away from your business and entity logic.
I use stored procedures in my production environment, and we process the rows too...