In my current environment I have a HUGE list of tables to scroll down through and finding that specific table I need to double-click is tedious (almost like trying to find a needle in a haystack).
Is there a way to open a specific table upon connecting to a database?
Alternatively, is there a way to create "shortcuts" (something like "favorites") to certain tables, so that they are easily accessible/findable upon SQL Developer startup?
I don't believe it is possible to set up a set of "Favorite" tables. However, if you right-click on Tables in your connection, there is an Apply Filter option. That lets you specify criteria to filter the set of tables that are displayed based on the name of the table or on other attributes like the last DDL time, etc. That's generally the easiest way to reduce the list to a reasonable number of tables.
Related
I have a multi tennant application which will use the SILO Model to save data (each tennant will get an own database).
Because tennant names could be redundand my database are with GUIDs: MyApp_[GUID].
Now I want to save simple but neccesary information for each database like a tennant name and 3 to 5 more informations.
Is there a simple way to write and get these data?
The only way I can think of is to create a special table for this with only 1 row - but it seems a bot of wasting.
If you're looking for a simpler solution than a table per database (and having to deal with the awkward constraint that it must have exactly one row), you could
use a custom configuration parameter. You can change them with ALTER DATABASE. The downside is that you can only store strings, and that the settings might be overridden per session.
use a COMMENT on the database. The downside is that you can only store a single string per databasebase; the advantage is that it is automatically shown in many lists of databases such as psql's \l+ command
add your own columns to the pg_database system table. You should not mess with that, so it's a spectacularly bad idea even if you knew what you were doing, but in a relational model it's the closest to what you were asking for so I'd mention it for completeness.
I don't really advocate any of these solutions, although they do what you were asking for there's probably a better solution to your actual problem. It might be as simple a table of databases, possibly with a foreign key to pg_database, in an extra database shared by all tenants.
I want to periodically export data from db2 and load it in another database for analysis.
In order to do this, I would need to know which rows have been inserted/updated since the last time I've exported things from a given table.
A simple solution would probably be to add a timestamp to every table and use that as a reference, but I don't have such a TS at the moment, and I would like to avoid adding it if possible.
Is there any other solution for finding the rows which have been added/updated after a given time (or something else that would solve my issue)?
There is an easy option for a timestamp in Db2 (for LUW) called
ROW CHANGE TIMESTAMP
This is managed by Db2 and could be defined as HIDDEN so existing SELECT * FROM queries will not retrieve the new row which would cause extra costs.
Check out the Db2 CREATE TABLE documentation
This functionality was originally added for optimistic locking but can be used for such situations as well.
There is a similar concept for Db2 z/OS - you have to check that out as I have not tried this one.
Of cause there are other ways to solve it like Replication etc.
That is not possible if you do not have a timestamp column. With a timestamp, you can know which are new or modified rows.
You can also use the TimeTravel feature, in order to get the new values, but that implies a timestamp column.
Another option, is to put the tables in append mode, and then get the rows after a given one. However, this option is not sure after a reorg, and affects the performance and space utilisation.
One possible option is to use SQL replication, but that needs extra tables for staging.
Finally, another option is to read the logs, with the db2ReadLog API, but that implies a development. Also, just appliying the archived logs into the new database is possible, however the database will remain in roll forward pending.
Sometimes, when I am creating reports, Microstrategy takes the wrong table for join (in case of using fields in report that appear in more than one table). For example if I have fact_table and fact_table_month, and they have the same fields, Microstrategy may take the fact_table_month for join when i need it to take tha fact_table.
i know about the possibility to create a dummy metrics and use them in the report. I know about the possibility to manually change the logical size of tables, but i am looking for an official and proper way to solve this problem in MSTR.
How can i force Microstrategy to take the table i want in join? how can I tell MSRT: ok, for this report use one table , and for that report use another?
MicroStrategy SQL Engine is dimensionally aware of the structure of your hierarchies. So if you have defined your attribute relationships, MicroStrategy should select the right fact table.
If your fact_table_month and fact_table have the same attributes and metrics, then it means the two tables have the same grain, so they are the same for MicroStrategy. If you think that metric A in fact_table_month is not a monthly aggregation of metric A fact_table then or the name of fact_table_month is wrong or your metrics should be two different facts and metrics.
In the past when I had a similar problem, the daily table populated from a system and the monthly from another, I solved using different metrics, unfortunately this didn't allow me to drill down easily.
Among the "tricks" to force the SQL Engine to use a specific table (beside logical size and a specific table), you can also add a specific attribute to report objects: an attribute present only in the lowest level of aggregation it's enough to hit the right table without additional dummy objects.
The best way always depend on your project and reporting requirements.
If you want precise control over your report then you can go for "Free Form SQL" report which requires you to manually write the SQL and use whatever joins you want.
Another way is to use the Lowest level attribute in the report object pane. Make sure that this attribute is stored at the specific level in the Fact table which you want to join.
Also you can take advantage of Metric Dimensionality i.e Filtering = None and Grouping = none whenever needed to join a specific fact table.
There is any way to include one or more columns in a specific order (after X column, for eg) in SQL Server 2005? Or something like change the master, or a sysobject, or a MODIFY command?
Please:
NOT MySQL (AFTER COLUMN doesn't work)
NOT DROP TABLE-CREATE TABLE (I can NOT implement this option on production without put down the application)
I can NOT touch the application, it's not my APP or APP.Team
I can NOT KNOW if there is somewhere in the application there is a SELECT * FROM so I must assume that YES, there is.
No, is not a desire, is an specific requirement, the table gets a feed from external source (app) through a job.
You can only add columns at the end.
And even that will use a schema modify lock for a short time, so in a very sensitive production environment, you should be aware of this.
http://msdn.microsoft.com/en-us/library/ms190273.aspx
If your app depends on a specific order of columns, the cure is not to change the column order, but to fix the app.
Some of the principles of RDBMS operation are better understood than others, and every definition of 1NF I know of concurs, that column order is to be considered without meaning.
I am currently in the process of setting up a database structure to manage events.
Events have properties which are stored in separate tables like 'location', 'timeslots', 'files' etc.
This in itself is not so difficult to set up. However, the tool needs to be able to host multiple events at the same time. So, for example a user can manage a the ABC event which occurs simultaneously with the DEF event. Obviously the database needs to be able to differentiate between these different events.
My first idea would be to add a table with unique identifiers describing the event (name:ABC) and then add a field to all my tables with this unique identifier.
This would however mean that the tool can become a bit slow because it has to query tables that contain data completely irrelevant to that particular event.
Are there any other solutions or should I just not worry about the bloat?
Answering a pretty old question, but it comes out 6th in a google query for postgre database events so it could be helpful to others: no, don't worry about it. Just create indices on the foreign key in the referencing tables to speed up the look up.