I'm curious as to how you handle instances where users want to know how to exclude columns that have sensitive data. I know explicitly listing the columns is an option but what do you do when you have tables/views with 50-100+ columns?
Example: Say I have a customer table that has 50 columns, I want to exclude 15 columns from the select as they hold sensitive data. I'm aware of all sensitive columns as I have a separate view that specifies them, is there any options to using this view to dynamically define the columns to select?
Appreciate any suggestions!
One possible solution I looked into was creating violatile tables and dropping the sensitive columns.
Related
I am making a SQLite database and want to have a way to add descriptions of the columns. For example, I may have table measurements with columns size and weight and want to add metadata on how the values in these columns were measured (eg. "Measured from fingertip to fingertip", "Measured at 10 AM").
How should I organize this extra information? In a separate table metadata with columns table, column and description? Wouldn't it be difficult to retrieve? Can I in some way use the descriptions as ALIAS?
EDIT. I am aware that it is not possible to add metadata directly to columns so the question is how to store the metadata in a way that makes them easily appendable/accessible when running queries on the corresponding columns
I have to prepare a table where I will keep weekly results for some aggregated data. Table will have 30 fields (10 CHARACTERs, 20 DECIMALs), I think I will have 250k rows weekly.
In my head I can see two scenarios:
Set table and relying on teradata in preventing duplicate rows - it should skip duplicate entries while inserting new data
Multi set table with UPI - it will give an error upon inserting duplicate row.
INSERT statement is going to be executed through VBA on excel, where handling possible teradata errors is not a problem.
Which scenario will be faster to run in a year time where there will be circa 14 millions rows
Is there any other way to have it done?
Regards
On a high level, since you would be having a comparatively high data count on your table, it is advisable not to use SET tables, rather go with the multiset table.
For more info you can refer to this link
http://www.dwhpro.com/teradata-multiset-tables/
Why do you care about Duplicate Rows? When you store weekly aggregates there should be no duplicates at all. And Duplicate Rows are not the same as duplicate Primary Key values.
Simply choose a PI which fits best your join/access pattern (maybe partition by date). To avoid any potential duplicates you might simply use MERGE instead of INSERT.
We have a website which is running on DNN 7.1 with SQL server. We implemented full text search to show search results. We need to search several tables and show the results to the user. Right now the implementation is user enters search word(s) and clicks search, the code behind creates several threads to search different tables, and merge the data. Currently we are using contains predicate, issue with this is, there is no ranking and sometimes after the merge the results on the first page are not the best matches. I thought that I can use containstable and order the results by ranking but I read ranking doesn't have any meaning by itself, it merely tells which one best matches in the current resultset. But in my scenario I have multiple resultsets, how will I know which are best matches across multiple resultsets. Or am I going about this wrong way? What is a good way to handle this scenario? We need to improve the response time along with better results. Any help is greatly appreciated.
this is how we implemented full text searching across multiple tables:
1) create a new table to store the primary keys of the other tables in each column, another column to store the string concatenated values of all the search fields from each table, and another column to store the checksum value of the concatenated values.
2) implement the FTI on this new table, and create a job that regularly syncrhonizes/updates the concatenated search values only if the binary_checksum value is different
3) use the contains predicate on this new table and based on the results, join back to their corresponding tables based on the primary keys returned.
This probably has a simple answer, but I've been looking all over and can't find anything to suit my needs.
I've been using gridviews to display data, but new customer requirements call for the user to be able to select individual columns, rows, or cells. Does anyone know of a good option?
Thanks.
EDIT:
Essentially, I'm displaying several rows of data, each row comprised of multiple columns. With standard gridviews you can't really select all the data in one column without selecting data from the other columns. I need a way for the user to select one column worth of data so that they can copy the data out.
If you're looking for commercial solution, check out Infragistics NetAdvantage for ASP.NET. Example of grid in action: http://www.infragistics.com/products/aspnet/sample/data-grid/selection-client-events
I have values in a SQLite table* that contain a number of strings, of different lengths, joined by periods, something like this:
SomeApp.SomeNameSpace.InterestingString.NotInteresting
SomeApp.OtherNameSpace.WantThisOne.ReallyQuiteDull
SomeApp.OtherNameSpace.WantThisOne.AlsoDull
SomeApp.DifferentNameSpace.AlwaysWorthALook.LittleValue
I'd like to extract (in this case) the third period-delimited substring so I could write something like
SELECT interesting_string, COUNT(*)
FROM ( SELECT third_part_of_period_delimited_string(name) interesting_string )
GROUP BY interesting_string;
Obviously I can do this any number of ways programmatically; I'm wondering if there's any way to achieve this in a SQLite SELECT query?
* It's a SharpDevelop Profiler database, if anyone's curious
No.
You can, as you mention, work with the strings after you have selected them from the database. Or you can split them up into separate columns when they are stored.
If you do not have access to the code that is storing the data, you might want to consider reading the data in its entirety, splitting the strings and storing the split out tokens in separate columns in a new table. If the data is not too large, you might look at storing this table in a new memory database to give excellent performance.
Whether this is worthwhile depends on whether one pass to split the data strings can be made use of many times. If the data is constantly changing, then this scheme would probably not work well.