I made a project with Spring Batch. However, due to the company's operating policy, foreign keys cannot be set in the meta table.
In this case, is it okay to make a table with only general columns and then insert data directly at the application level?
If there is another solution, please let me know.
due to the company's operating policy, foreign keys cannot be set in the meta table
How is your company planning to deal with data consistency without foreign keys? Your company's policies should really be reviewed.
The answer to your question is yes. You should be able to use Spring Batch without adding the foreign keys in its meta-data schema, but you obviously risk to have data inconsistencies and some undefined consequences in some cases.
Related
We are a team of tens of data analysts. Our main data back-end is an Oracle database. We use personal schemas to do work where we don't need to collaborate with others and we would like to create schemas dedicated to projects where people need to collaborate.
The problem is that in Oracle, one schema is equivalent to one DB user. If we create a schema dedicated to a project, for the purpose of creating DB objects in the context of that project, there will be a single set of credentials (username + password) that needs to be shared by all team members. This has two inconveniences:
if people mistype the credentials, they can block the account for everyone;
it is no longer possible to monitor who did what for security/audit reasons, since everyone uses the same schema;
An alternative would be that only one person uses the Schema user to create objects and assigns privileges to other people in those objects, but that can become quickly cumbersome.
Another alternative is to interact with the DB through R or Python but that means the credentials will be stored in some text file, which is bad for security.
As we see it, the ideal situation is if multiple personal DB users can create objects in the same schema, and if those objects are automatically available for that set of DB users. Is this totally impossible in Oracle? Is this impossible in any major DB? Is this requirement somehow flawed and as such, there is a good reason for why it is not available?
We could compare this collaboration in a DB schema to what commonly happens with people collaborating in a folder, using R, Python or other programming language for data analytics.
Thank you for your advise!
Maybe I miss something but could you not just create a schema that will be used for all users and grant the required privileges to each individual user?
Each user authenticates with his local account and by default uses his local schema and to access the public one you just use the ALTER SESSION SET CURRENT_SCHEMA command.
I'm working on a simple task of adding a new table to an existing SQL DB and wiring it into a SpringBoot API with SpringData.
I would typically start by defining the DB table directly, creating PK and FK, etc and then creating the Java bean that represents it, but am curious about using the SpringData initialization feature.
I am wondering when and where Spring Data + JPAs schema generation and DB initialization may be useful. There are many tutorials on how it can be implemented, but when and why are not as clear to me.
For example:
Should I convert my existing lower environment DBs (hand coded) to initialized automatically? If so, by dropping the existing tables and allowing the App to execute DDL?
Should this feature be relied on at all in production envrionment?
Should generation or initialization be run only once? Some tutorial mention this process running continually, but why would you choose to lose data that often?
What is the purpose of the drop-and-create jpa action? Why would
you ever want to drop tables? How are things like UAT test data handled?
My two cents on these topics:
Most people may say that you should not rely on automated database creation because it is a core concept of your application and you might want to take over the task so that you can lnowmfor sure what is really happening. I tend to agree with them. Unless it is a POC os something not production critical, I would prefer to define the database details myself.
In my opinion no.
This might be ok on environments that are non-productive. Or on early and exploratory developments. Definetely not on production.
On a POC or on early and exploratory developments this is ok. In any other case I see this being useful. Test data might also be part of the initial setup of the database. Spring allows you to do that by defining an SQL script inserting data to the database on startup.
Bottomline in my opinion you should not rely on this feature on Production. Instead you might want to take a look at liquibase or flyway (nice article comparing both https://dzone.com/articles/flyway-vs-liquibase), which are fully fledged database migration tools on which you can rely even on production.
My opinion in short:
No, don't rely on Auto DDL. It can be a handy feature in development but should never be used in production. And be careful, it will change your database whenever you change something on your entities.
But, and this is why I answer, there is a possibility to have hibernate write the SQL in a file instead of executing it. This gives you the ability to make use of the feature but still control how your database is changed. I frequently use this to generate scripts I then use as blueprint for my own liquibase migration scripts.
This way you can initially implement an entity in the code and run the application, which generates the hibernate sql file containing the create table statement for your newly added entity. Now you don't have to write all those column names and types for the database table yourself.
To achieve this, add following properties to your application.properties:
spring.jpa.hibernate.ddl-auto=none
spring.jpa.properties.javax.persistence.schema-generation.scripts.create-target=build/generated_scripts/hibernate_schema.sql
spring.jpa.properties.javax.persistence.schema-generation.scripts.action=create
This will generate the SQL script in your project folder within build/generated_scripts/hibernate_schema.sql
I know this is not exactly what you were asking for but I thought this could be a nice hint on how to use Auto DDL in a safer way.
I have an ERP application running with Oracle forms and Oracle database. Now I am planning to migrate this application to a java based enterprise application. will it be a good idea to keep the existing oracle database as back end and developing a web application with certain level of changes/additions in the DB design.
There are two facts to know before answer your questions:
has your database schema some oracle forms special structures or is it in 3rd normal form and simply stores data using keys and enforced referential integrity?
How much stored code contains your database?
Ad 1. Oracle forms don't have specific schema reqiurements. They work best if your schema if based on 3rd normal form. If your schema is like this, use it for new Java application. We have both forms and Java EE applications on same database schemas and is works fine.
Advantage is, if you have keys (primary, unique, foreign) in your schema. Use them when generating Java app.
Probably you will have to add #Version columns for optimistic locking (see https://docs.oracle.com/javaee/6/api/javax/persistence/Version.html). But there is not reason to build new schema for it.
Ad 2. Your will have to overwrite bigger part of database stored code (triggers, procedures, functions) to Java. In most cases this does not have dramatic impact to schema structure, but deal with it.
So - if your database schema is not tailored to some UI client needs AND you want only use a new client, use your schema. If not, create a new one.
I'm using VWD 2008 Express Edition with MVC and I am trying to add a foreign key from my database to the ASPNET Membership database's Users table. Is this possible using the user interface or do I have to scrounge up some SQL every time I want to do this?
Edit: After thinking about this for a minute, I realized that maybe having an FK to a different DB wasn't even possible... I really didn't think about my question thoroughly enough, did I?
There is no API for that. Script your database once you created the membership tables and use your script from there on. (BTW, you don't have to use that table structure to use the membership provider if it doesn't suit your needs.)
Why does a user needs privileges over his own schema to create packages and triggers?
Are you asking why users need particular priviliges (i.e. CREATE TABLE, CREATE PROCEDURE, etc) in order to create particular types of objects in their own schema?
If so, the natural answer would be that good security begins with the principle of least privilege-- that is, a user should only have those privileges that they truly need to do their job and no more. DBAs frequently want to create read-only accounts for users in the production database (business analysts, for example, often need to do different sorts of ad hoc reporting, developers may need access to troubleshoot certain types of problems, etc). If a user were always able to create objects in their own schema, those read-only users would suddenly be able to deploy code to the production database without going through change control or even necessarily testing anything. And that generally leads to a proliferation in code doing basically the same thing (i.e. a dozen analysts each have a procedure to calculate sales tax in their own schemas) but each of which has its own unique signature, logic, requirements, assumptions, etc. And heaven forbid that one of those analysts get fired because the DBA would naturally delete their account, only to find out that some crucial report depended on code that existed only in that analyst's schema.
I can't give you the "official" answer, but I can take a stab at the reasoning behind how it works. On the project I work on, Oracle Developers are the ones that deploy the triggers and packages into the database schema. But we have other teams of Java developers and testers, etc. Once the schema are migrated into the Test and then Production environments, we don't want the testers or the end user applications to be able to arbitrarily modify the triggers and packages associated with that schema, as that could invalidate the integrity of any testing they are doing (or cause even worse issues on the production system).
So within the test/production environments, you want the testers, the Java developers, and the end-user application to be able to read and write data to the schema, but not modify the triggers and packages which encompass the baselined code.
Why does a user needs privileges over
his own schema to create packages and
triggers
They do not.
Their own schema implies the ownership (or namespace) defined by username.object
All a user needs to create a trigger in their own schema is:
a table in their own schema
the create trigger privilege
All a user needs to create a package in their own schema is:
the create package privilege
If the user wants to create objects in another schema or that references other objects, or that requires storage in a tablespace then they will need permissions on those foreign objects.