I have 3 folders on a server:
PROJECT_1_TEST
PROJECT_1_INT
PROJECT_1_PROD
Each folder contains a universe.
The only difference among universes is that they use different databases - test, integration, production db respectively.
The question is - when I change something in TEST folder, would it be possible just to copy the universe from TEST -> INT or PROD so that the universe in these two folders automatically gets the new changes?
I want to avoid multiple identical changes for every of these universes.
Is it possible to use for example a parameter that uses TEST DB when a universe is in TEST folder, INT DB when a universe is in INT DB, and PROD DB when a universe is in PROD folder???
If you're using IDT, you can quite easily publish the same BL as 3 different universes. The only thing you'll need to remember is to change the connection as you cannot make the connection dependant on the folder the universe resides in.
What you could do is use one single universe, and depending on the user, change the underlying connection.
For example, say you have 3 user accounts:
user A (test)
user B (int)
user C (prod)
Using Data Security Profiles (or universe restrictions in UDT), you can define that the test connection should be used when user A uses a document on your universe, or the int connection when user B does, etc.
Of course, you wouldn't do this with individual users but rather with user groups. Make sure though that a user is a member of only one of these groups.
The advantage is that you end up with only one universe to maintain and publish. However, I don't know you use case, so this may or may not fit.
Look in the Information Design Tool User Guide section 17.7 for more information on this.
Related
I'm learning how to design a DB structure for assigning users permission to access certain pages
if the user is an admin that user would have access to crud operations
if the user is an editor that user would have access to only edit
user can have custom permission then access it would vary depending on the config
I have two schema designs and both seems good, one requires simple queries and the other can hold more description about each role and permission.
Design 1
role id is stored in a table called user and i will need to lookup role_has_permission table get all the permission ids then lookup permission table to get the permission_name column. comparatively longer query with more data being fetched, but i can have description column in permission table
Design 2
role id stored in table user, i can simply make a single query and check for permission. eg: role.canEdit is set to true user is allowed to edit. smaller and faster query.
why cant i go with the second design? and why do many articles go with the first design?
Design 1 lets you add permissions dynamically without changing the software. If you need a new permission, say can order lunch for entire team, you just add a record in the permission table and as many in the role_has_permission as needed, and you're done. In design 2 you'd have to add an operation canOrderLunchForEntireTeam. So design 1 is more flexible.
However, the flexibility of design 1 has a price. It's not enough to define and assign these permissions, but the software shall probably also check them when a function is performed. Adding a function for ordering lunch is a software change anyway, so adding an attribute to your design 2 class might be tolerable. The generic way of defining permissions in design 1 will therefore only pay out if you implement a similarly generic way of applying them.
I have a growing web system of around 30,000 users.
There's a few actions on the web system that are disabled for most users. But some trusted clients might be given the privilege to use them.
I already have an object that handles the permissions for each user (get/set). Those permissions are represented in each user database entry as an Integer Field (each bit is a permission).
In my first option I would add a new permission field on my permission manager object for each whitelist that I would want to implement. Then when I would like to know if the current user is on the whitelist, I would call this object and check that permission.
But if would show to the admin a whitelist (display, edit, delete, etc), then I would have to create a permission manager object 30,000 times and test each permission. Which I think is very wasteful.
My second option is to create a new table whitelists and each row would be a different whitelist, then in a TEXT field I would write a comma separated list of users ids. The problem: TEXT VARCHAR or any kind of text field has a character count limit.
I think that the most efficient way is the second option since it's improbable that I would put more than 100 users in the whitelist.
But there's a better implementation?
Maybe I could add a new method to my permission manager object that would use only one query to build lists for a selected permission.
a conceptual question:
I have a global system which sales agents use to write orders for clients
Agents can register a client locally (within their own instance of the system)
a client can register himself globally
Agents have access to clients based on client-ID and zipcode
Condition:
I cannot have duplicate clients in the system.
Therefore I need to check during registration, if a client already exists.
I can only make a check on zipcode, because client-ID is an instance-based identifier (a client may have ID-123 in instance A and ID-456 in instance B).
Problem:
Is there a way around showing existing clients with exactly matching zipcode to whoever makes a registration since I don't really want to display something like:
please select one of the following:
Zip 12345 - City: Bigcity - Company Name: some corp.
Zip 12345 - City: Bigcity - Company Name: some other corp.
Zip 12345 - City: Bigcity - Company Name: small ltd.
or create new account
to whoever tries to register.
I cannot modify the global/local structure of the system, but I could add elements or identifiers if this helps.
I hope this is enough info to give some input. Let me know if you need more.
Thanks!
If you don't want to show this dialog for confidentiality reasons, then there is little you can do. The input data just doesn't allow to make any hard decisions programmatically. There could be a typo or something, so I wouldn't trust a program to tinker this together for me. I think the only thing you could do is putting new registrations on a shelf, and only add them to the global database, when they have been confirmed as non-duplicate. You could run a process once per hour that does this.
Find all new registrations within the last hour.
For each registration: find possible duplicate in the existing database.
If duplicate exists: notify manager to handle this manually.
If no duplicate exists: confirm the registration, add it to the database.
You could also write a small tool for the person responsible for handing duplicates, that merges the new registration with an existing client and does whatever is required in that case (e.g. notify the person who did the registration, sending the new client-id, etc).
I have database A and database B. I would like to do one way replication from A to B.
The only hitch is [A].[dbo].[table] needs to replicate to [B].[someschema].[table]. Is this easy (or possible to do)? The key requirement is that I have real time synch. I do not need to transform the table definition at all in db B.
Short answer yes, you can do this, but not without some effort.
FROM BOOKS ONLINE:
Schemas and Object Ownership
Replication has the following default behavior in the New Publication Wizard with respect to schemas and object ownership:
For articles in merge publications with a compatibility level of 90 or higher, snapshot publications, and transactional publications: by default, the object owner at the Subscriber is the same as the owner of the corresponding object at the Publisher. If the schemas that own objects do not exist at the Subscriber, they are created automatically.
For articles in merge publications with a compatibility level lower than 90: by default, the owner is left blank and is specified as dbo during the creation of the object on the Subscriber.
The object owner can be changed through the Article Properties - dialog box and through the following stored procedures: sp_addarticle, sp_addmergearticle, sp_changearticle, and sp_changemergearticle. For more information, see
http://msdn.microsoft.com/en-us/library/ms151197.aspx
I will have multiple tables used by different projects on the same mySql server. Much of the data is sensitive, and needs to be behind permissions wall. However many of the tables of sensitive data rely on tables of insensitive data for user and department information. So I see three options ahead of me and I am unsure which one to pick.
All in one database with table level permissions
The simplest of all solutions except I don't control permissions on the database server, traditionally the server team only does database level permissions and getting them to allow it is a political battle I may not have the influence to win, and keeping track of all the permissions would be a pain.
In multiple databases, with database level permissions
I can split the tables into database zones, so department wide info, like the staff data, can be in it's own database and tools that edit the staff data can have UPDATE&INSERT access to the department database. Other tools would want to access parts of the staff list, the public staff directory have SELECT access to the to the staff tables, but pars of the staff tables would need to remain private, like personal contact info, copy codes, or billing indexes. I would need to split the staff tables into public or private tables, but I would be stuck with table level permissions again. So I would need to split the department database into the department shared and the department private databases.
Cross database views
I would create views in a database that pulls data from other databases that the account does not have access to. So I can put all the staff information in the department database, then create a view in the web database that only pulls the columns that should be publicly available (name, department, extension). This would allow me to, in effect, have column level SELECT rights without having to muck about with permissions. My concern would be speed. The original table the data is being pulled from would be fully indexed but the documentation seems contradictory whether or not the columns would be indexed when querying the view.
Has anyone else used any of these three options? Do you have better ones that I haven't thought of? What are the pitfalls you can see beyond what I have pointed out for any of the options?
Views and stored-procedures are your best bet. Views can be used to provide generic access, but if some queries under-perform, re-write them to use stored-procedures bypassing the view for performance.