Best practice for existing target table

We want to develop mappings for existing target tables.
1. The tables are imported from the datadictionary
2. The tables are used in the mappings
Is it a good idea to set deploy to no for these tables, to prevent them from beeing used by the deplomentmanager (default action:create)?
Thanks your for a good practice
Stp
Message was edited by:
user444776
Message was edited by:
user444776

Hi,
Yes, you are right. for the tables which already exist in the database schema the deployment actions should be "None". Unless you planned and made any changes to the table structures.
Cheers
Mahesh

Similar Messages

JDeveloper 11.1.1.3: Best Practice for Checkboxes in Table

Hi there,
I'm having problems with checkboxes inside the table component.
Can someone please fill me in as to what the best practice is to use checkboxes inside a table ?
In the database, we are storing values Y and N.
Thanks,
Mark

Hi Mark,
I suppose you are talking about ADF Faces applications. If so, then I have two prefered approaches tested and used in real practice:
*1) First approach: Create a simple converter, define it in the faces-config.xml and set it in the <af:selectBooleanCheckbox> tags' "converter" attribute, for example:*
package mypackage;
import javax.faces.application.FacesMessage;
import javax.faces.component.UIComponent;
import javax.faces.context.FacesContext;
import javax.faces.convert.Converter;
import javax.faces.convert.ConverterException;
public class BooleanYNConverter implements Converter {
public BooleanYNConverter() {
public Object getAsObject(FacesContext facesContext, UIComponent uiComponent, String string) {
    if (string==null) return null;
    String s = string.trim();
    if (s.length()==0) return null;
    if (s.equalsIgnoreCase("true")) return "Y";
    if (s.equalsIgnoreCase("false")) return "N";
    FacesMessage errorMessage = new FacesMessage(FacesMessage.SEVERITY_ERROR,
        "Cannot convert " + string + " to Y/N. It must be either true or false",
        "Cannot convert " + string + " to Y/N. It must be either true or false" );
    throw new ConverterException(errorMessage);
public String getAsString(FacesContext facesContext, UIComponent uiComponent, Object object) {
    if (object == null) return "";
    if (object.equals("Y")) return "true";
    if (object.equals("N")) return "false";
    FacesMessage errorMessage = new FacesMessage(FacesMessage.SEVERITY_ERROR,
        "Cannot convert " + object + " to true/false. It must be either Y or N",
        "Cannot convert " + object + " to true/false. It must be either Y or N" );
    throw new ConverterException(errorMessage);
}In faces-config.xml:
<converter>
    <converter-id>BooleanYNConverter</converter-id>
    <converter-class>mypackage.BooleanYNConverter</converter-class>
</converter>In JSF page:
<af:selectBooleanCheckbox ... converter="BooleanYNConverter"/>
N.B. If you use this approach, the ViewObject attribute's Control Type should be set to "Default" instead of "Checkbox" (see the attribute's Control Hints section in the dialog box)!
*2) Second approach: In the PageDef define a button binding for Y/N values and map the corresponding item in the table binding to this button binding. In this way you will remap VO attribute's Y/N value to true/false as how the checkbox component expects it. Neither converters nor additional configuration is necessary, but you have to do this on each checkbox field again:*
<?xml version="1.0" encoding="UTF-8" ?>
<pageDefinition xmlns="http://xmlns.oracle.com/adfm/uimodel" version="11.1.1.56.60" id="TestPagePageDef" Package="view.pageDefs">
<parameters/>
<executables>
    <variableIterator id="variables"/>
    <iterator Binds="DeptViewRO" RangeSize="25" DataControl="AppModuleDataControl" id="DeptViewROIterator"/>
</executables>
<bindings>
    <tree IterBinding="DeptViewROIterator" id="DeptViewRO">
      <nodeDefinition DefName="model.DeptViewRO" Name="DeptViewRO0">
        <AttrNames>
          <Item Value="DeptID"/>
          <Item Value="DeptName"/>
          <Item Value="Flag" Binds="MyFlag"/>
        </AttrNames>
      </nodeDefinition>
    </tree>
    <button IterBinding="DeptViewROIterator" StaticList="true" id="MyFlag">
      <AttrNames>
        <Item Value="Flag"/>
      </AttrNames>
      <ValueList>
        <Item Value="Y"/>
        <Item Value="N"/>
      </ValueList>
    </button>
</bindings>
</pageDefinition>In the sample above the target VO attribute is called Flag. Have a look at the line <tt><Item Value="Flag" Binds="MyFlag"/></tt>. This line does the magic.
Hope I've been a bit helpful.
Dimitar
Edited by: Dimitar Dimitrov on Nov 13, 2010 1:53 PM
There was a little mistake: Instead of BooleanYNConverter I had written BooleanYNCheckbox in the <af:selectBooleanCheckbox> tag.

Best practice for migrating data tables- please comment.

I have 5 new tables seeded with data that need to be promoted from a development to a production environment.
Instead of the DBAs just using a tool to migrate the data they are insistent that I save and provide scripts for every single commit, in proper order, necessary to both build the table and insert the data from ground zero.
I am very unaccustomed to this kind of environment and it seems much riskier for me to try and rebuild the objects from scratch when I already have a perfect, tested, ready model.
They also require extensive documentation where every step is recorded in a document and use that for the deployment.
I believe their rationale is they don't want to rely on backups but instead want to rely on a document that specifies each step to recreate.
Please comment on your view of this practice. Thanks!

>
Please comment on your view of this practice. Thanks!
>
Sounds like the DBAs are using best practices to get the job done. Congratulations to them!
>
I have 5 new tables seeded with data that need to be promoted from a development to a production environment.
Instead of the DBAs just using a tool to migrate the data they are insistent that I save and provide scripts for every single commit, in proper order, necessary to both build the table and insert the data from ground zero.
>
The process you describe is what I would expect, and require, in any well-run environment.
>
I am very unaccustomed to this kind of environment and it seems much riskier for me to try and rebuild the objects from scratch when I already have a perfect, tested, ready model.
>
Nobody cares if if is riskier for you. The production environment is sacred. Any and all risk to it must be reduced to a minimum at all cost. In my opinion a DBA should NEVER move ANYTHING from a development environment directly to a production environment. NEVER.
Development environments are sandboxes. They are often not backed up. You or anyone else could easily modify tables or data with no controls in place. Anything done in a DEV environment is assumed to be incomplete, unsecure, disposable and unvetted.
If you are doing development and don't have scripts to rebuild your objects from scratch then you are doing it wrong. You should ALWAYS have your own backup copies of DDL in case anything happens (and it does) to the development environment. By 'have your own' I mean there should be copies in a version control system or central repository where your teammates can get their hands on them if you are not available.
As for data - I agree with what others have said. Further - ALL data in a dev environment is assumed to be dev data and not production data. In all environments I have worked in ALL production data must be validated and approved by the business. That means every piece of data in lookup tables, fact tables, dimension tables, etc. Only computed data, such as might be in a data warehouse system generated by an ETL process might be exempt; but the process that creates that data is not exempt - that process and ultimately the data - must be signed off on by the business.
And the business generally has no access to, or control of, a development environment. That means using a TEST or QA environment for the business users to test and validate.
>
They also require extensive documentation where every step is recorded in a document and use that for the deployment.
I believe their rationale is they don't want to rely on backups but instead want to rely on a document that specifies each step to recreate.
>
Absolutely! That's how professional deployments are performed. Deployment documents are prepared and submitted for sign off by each of the affected groups. Those groups can include security, dba, business user, IT and even legal. The deployment documents always include recovery steps so that is something goes wrong or the deployment can't procede there is a documented procedure of how to restore the system to a valid working state.
The deployments themselves that I participate in have representatives from the each of those groups in the room or on a conference call as each step of the deployment is performed. Your 5 tables may be used by stored procedures, views or other code that has to be deployed as part of the same process. Each step of the deployment has to be performed in the correct order. If something goes wrong the responsible party is responsible for assisting in the retry or recovery of their component.
It is absolutely vital to have a known, secure, repeatable process for deployments. There are no shortcuts. I agree, for a simple 5 new table and small amount of data scenario it may seem like overkill.
But, despite what you say it simply cannot be that easy for one simple reason. Adding 5 tables with data to a production system has no business impact or utility at all unless there is some code, process or application somewhere that accesses those tables and data. Your post didn't mention the part about what changes are being made to actually USE what you are adding.

Best Practice for Designing Database Tables?

Hi,
I work at a company for tracking devices (GPS Devices). Our SQL Server database is designed to have a table for each device we sell, currently there is 2500 tables in our database and they all have the same columns they only differ in table name. Each device
sends about 4K records per day.
currently each table hold from 10K records to 300K records
What is the best practice to design a database in this situation?
When accessing database from a C# application, which is better to use, direct SQL commands or views?
a detailed description about what is best to do in such scenario would be great.
Thanks in advance.
Edit:
Tables columns are:
[MessageID]
,[MessageUnit]
,[MessageLong]
,[MessageLat]
,[MessageSpeed]
,[MessageTime]
,[MessageDate]
,[MessageHeading]
,[MessageSatNumber]
,[MessageInput]
,[MessageCreationDate]
,[MessageInput2]
,[MessageInput3]
,[MessageIO]

Hello Louis, thank you so much for your informative post. I'll describe in detail what situations I came through my 9 months of work in the company (working as a software engineer, but I am planning to take over database maintenance since no one is maintaining
it right now and I cannot do anything else in the code to make it faster)
At every end of the month our clients generate report for the previous month for all their cars, some clients have 100+ cars, and some have few. This is when real issue start, they are calling their data from our server through internet while having 2000
unit sending data to our server, they keep on getting read time out since SQL Server gives priority to insert and hold all select commands. I solved it temporary in the code using "Read Uncommitted" once I initialize a connection through C#.
The other issue is generating reports for a month or two takes lots of time when selecting 100+ units. Thats what I want to solve, the problem is the one who wrote the C# app used hard coded SQL Statements
AND
the company is refusing to upgrade from SQL Server 2003 and Windows Server 2003.
Now talking about reports, there are summary reports, stops reports, zone reports ..etc most of them depend usually on at least MessageTime, MessageDate, MessageSpeed, MessageIO and MessageSatNumber.
So from your post I conclude that for now I need to set snapshots so that select statements don't get kicked out in favor for insert commands, but does SQL Server automatically select from the snapshots or do I have to tell it to do so?
Other than proper indexing what else I need? Tom
Phillips suggested Table partitioning but I don't think it is needed in my case since our database size is 78GB
When I run code analysis on the app, Visual Studio tells me I better use stored procedures, views than using hard coded Select Statements, what difference will this bring me when talking about performance?
Thanks in advance.

Best practice for archiving FGA_LOG$ table?

Hi all,
I am running Oracle 11g Release 1, and have been asked to look at how to best archive the FA_LOG$ table. We are required to store the logs for 3 years. I ran the following query:
select owner, segment_name, segment_type, bytes/1024/1024 "MB" from dba_segments
where tablespace_name = 'AUDIT_TBS' AND rownum <=100
AND bytes/1024/1024 > 1 order by bytes desc;
and it shows that the FGA_LOG$ table is currently at 84861 MB!
Is my best course of action to:
1. Install the patch necessary to access the DBMS_AUDIT_MGMT package
2. Move the table to a different tablespace
3. Use the DataPump export utlity
4. Cleanup the table with the DBMS_AUDIT_MGMT package?
Thanks,
David

to remove from the table itself
delete from fga_log$ where timestamp# < sysdate-(365*3);
if you want to keep data outside
expdp to a file called this_years_fga_data.dmp , zip up and keep wherever you like.
truncate fga_log$
repeat annually
* edit, jsut to clarify the timestamp# column may depend on version.
Edited by: deebee_eh on Apr 25, 2012 5:05 PM

Best Practice for Running Number Table

Dear All
Thank you for your attention.
I would like to generate number for each order
AAAA150001
AAAA is prefix
1 is year and 0001 is he sequence number.
I proposed the table as below
Prefix | Year | Number
AAAA | 15 | 1
Using SQL query as below to get the lastest number
SELECT CurrentNumber = Prefix + Year + RIGHT ('0000'+ CAST (Number+1 AS VARCHAR(4)), 4)
FROM RunningNumber WHERE Prefix = 'AAAA'
after all save process then update the running number table
UPDATE RunningNumber SET Number = (Number +1) WHERE Prefix = 'AAAA' AND Year = '15'
Is that a normal approach and good to handle concurrent saving?
Thanks.
Best Regards
mintssoul

Dear Visakh16
Each year the number will reset, table will as below
Prefix | Year | Number
AAAA | 15 | 8749
AAAA | 16 | 1
I could only use option1 from your ref.
To use this approach, I must make sure
a) the number will not be duplicated or jumped as there is multiple users using the system concurrently.
b) the number will not increment when there is any error after get the new number
Is that using the following methods could archive a) & b)?
1) .NET SqlTransaction.Rollback
2) SQL
ROLLBACK TRANSACTION Thanks.
To prevent repeat information, details of 1) & 2) is not listed here, please refer to my previous reply to Uri
thanks.
Best Regardsmintssoul

Best practice for replicating Partitioned table

Hi SQL Gurus,
Requesting your help on the design consideration for replicating a partitioned table.
1. 4 Partitioned tables (1 master table with foreign key constraints to 3 tables) partitioned based on monthly YYYYMM
2. 1 table has a XML column in it
3. Monthly switch partition to remove old data, since it is having foreign key constraint; disable until the switch is complete
4. 1 month partitioned data is 60 GB
having said the above, wanted to create a copy of the same tables to a different servers.
I can think of
1. Transactional replication, but then worried about the XML column,snapshot size and the alter switch will make the same thing
on the subscriber or row by row delete.
2. Logshipping with standby with every 15 minutes, but then it will be for the entire database; because I have other partitioned monthly table which is of 250 GB worth.
3. Thinking about replicating the Partitioned table as Non Partitioned, in that case how the alter switch will work. Is it possible to ignore delete when setting up the replication.
3. SSIS or Stored procedure method of moving data on a daily basis.
4. Backup and restore on a daily basis, but this will not work when the source partition is removed.
Ganesh

Plz refer to
http://msdn.microsoft.com/en-us/library/cc280940.aspx

What is the best practice for inserting (unique) rows into a table containing key columns constraint where source may contain duplicate (already existing) rows?

My final data table contains a two key columns unique key constraint. I insert data into this table from a daily capture table (which also contains the two columns that make up the key in the final data table but are not constrained
(not unique) in the daily capture table). I don't want to insert rows from daily capture which already exists in final data table (based on the two key columns). Currently, what I do is to select * into a #temp table from the join
of daily capture and final data tables on these two key columns. Then I delete the rows in the daily capture table which match the #temp table. Then I insert the remaining rows from daily capture into the final data table.
Would it be possible to simplify this process by using an Instead Of trigger in the final table and just insert directly from the daily capture table? How would this look?
What is the best practice for inserting unique (new) rows and ignoring duplicate rows (rows that already exist in both the daily capture and final data tables) in my particular operation?
Rich P

Please follow basic Netiquette and post the DDL we need to answer this. Follow industry and ANSI/ISO standards in your data. You should follow ISO-11179 rules for naming data elements. You should follow ISO-8601 rules for displaying temporal data. We need
to know the data types, keys and constraints on the table. Avoid dialect in favor of ANSI/ISO Standard SQL. And you need to read and download the PDF for:
https://www.simple-talk.com/books/sql-books/119-sql-code-smells/
>> My final data table contains a two key columns unique key constraint. [unh? one two-column key or two one column keys? Sure wish you posted DDL] I insert data into this table from a daily capture table (which also contains the two columns that make
up the key in the final data table but are not constrained (not unique) in the daily capture table). <<
Then the "capture table" is not a table at all! Remember the fist day of your RDBMS class? A table has to have a key. You need to fix this error. What ETL tool do you use?
>> I don't want to insert rows from daily capture which already exists in final data table (based on the two key columns). <<
MERGE statement; Google it. And do not use temp tables.
--CELKO-- Books in Celko Series for Morgan-Kaufmann Publishing: Analytics and OLAP in SQL / Data and Databases: Concepts in Practice Data / Measurements and Standards in SQL SQL for Smarties / SQL Programming Style / SQL Puzzles and Answers / Thinking
in Sets / Trees and Hierarchies in SQL

What is the best practice for creating primary key on fact table?

what is the best practice for primary key on fact table?
1. Using composite key
2. Create a surrogate key
3. No primary key
In document, i can only find "From a modeling standpoint, the primary key of the fact table is usually a composite key that is made up of all of its foreign keys."
http://download.oracle.com/docs/cd/E11882_01/server.112/e16579/logical.htm#i1006423
I also found a relevant thread states that primary key on fact table is necessary.
Primary Key on Fact Table.
But, if no business requires the uniqueness of the records and there is no materilized view, do we still need primary key? is there any other bad affect if there is no primary key on fact table? and any benifits from not creating primary key?

Well, natural combination of dimensions connected to the fact would be a natural primary key and it would be composite.
Having an artificial PK might simplify things a bit.
Having no PK leads to a major mess. Fact should represent a business transaction, or some general event. If you're loading data you want to be able to identify the records that are processed. Also without PK if you forget to make an unique key the access to this fact table will be slow. Plus, having no PK will mean that if you want to used different tools, like Data Modeller in Jbuilder or OWB insert / update functionality it won't function, since there's no PK. Defining a PK for every table is a good practice. Not defining PK is asking for a load of problems, from performance to functionality and data quality.
Edited by: Cortanamo on 16.12.2010 07:12

Best Practice for Extracting a Single Value from Oracle Table

I'm using Oracle Database 11g Release 11.2.0.3.0.
I'd like to know the best practice for doing something like this in a PL/SQL block:
DECLARE
    v_student_id    student.student_id%TYPE;
BEGIN
    SELECT student_id
    INTO    v_student_id
    FROM    student
    WHERE   last_name = 'Smith'
    AND     ROWNUM = 1;
END;
Of course, the problem here is that when there is no hit, the NO_DATA_FOUND exception is raised, which halts execution. So what if I want to continue in spite of the exception?
Yes, I could create a nested block with EXCEPTION section, etc., but that seems clunky for what seems to be a very simple task.
I've also seen this handled like this:
DECLARE
    v_student_id    student.student_id%TYPE;
    CURSOR c_student_id IS
        SELECT student_id
        FROM    student
        WHERE   last_name = 'Smith'
        AND     ROWNUM = 1;
BEGIN
    OPEN c_student_id;
    FETCH c_student_id INTO v_student_id;
    IF c_student_id%NOTFOUND THEN
        DBMS_OUTPUT.PUT_LINE('not found');
    ELSE
        (do stuff)
    END IF;
    CLOSE c_student_id;
END;
But this still seems like killing an ant with a sledge hammer.
What's the best way?
Thanks for any help you can give.
Wayne

Do not design in order to avoid exceptions. Do not code in order to avoid exceptions.
Exceptions are good. Damn good. As it allows you to catch an unexpected process branch, where execution did not go as planned and coded.
Trying to avoid exceptions is just plain bloody stupid.
As for you specific problem. When the SQL fails to find a row and a value to return, what then? This is unexpected - if you did not want a value, you would not have coded the SQL to find a value. So the SQL not finding a value is an exception to what you intend with your code. And you need to decide what to do with that exception.
How to implement it. The #1 rule in software engineering - modularisation.
E.g.
create or replace function FindSomething( name varchar2 ) return foo.col1%type is
id foo.col1%type;
begin
select col1 into id from foo where col2 = upper(name);
return( id );
exception when NOT_FOUND then
return( null );
end;
And that is your problem. Modularisation. You are not considering it.
And not the only problem mind you. Seems like your keyboard has a stuck capslock key. Writing code in all uppercase is just as bloody silly as trying to avoid exceptions.

Best practice for external but secure access to internal data?

We need external customers/vendors/partners to access some of our company data (view/add/edit). It’s not so easy as to segment out those databases/tables/records from other existing (and put separate database(s) in the DMZ where our server is). Our
current solution is to have a 1433 hole from web server into our database server. The user credentials are not in any sort of web.config but rather compiled in our DLLs, and that SQL login has read/write access to a very limited number of databases.
Our security group says this is still not secure, but how else are we to do it? Even if a web service, there still has to be a hole in somewhere. Any standard best practice for this?
Thanks.

Security is mainly about mitigation rather than 100% secure, "We have unknown unknowns". The component needs to talk to SQL Server. You could continue to use http to talk to SQL Server, perhaps even get SOAP Transactions working but personally
I'd have more worries about using such a 'less trodden' path since that is exactly the areas where more security problems are discovered. I don't know about your specific design issues so there might be even more ways to mitigate the risk but in general you're
using a DMZ as a decent way to mitigate risk. I would recommend asking your security team what they'd deem acceptable.
http://pauliom.wordpress.com

What are best practice for packaging and deploying j2EE apps to iAS?

We've been running a set of J2EE applications on a pair of iAS SP1b for about a year and it has been quite stable.
Recently however we have had a number of LDAP issues, particularly when registering and unregistering applications (registering ear files sometimes fails 1st time but may work 2nd time). Also We've noticed very occasionally that old versions of classes sometimes find their way onto our machines.
What is considered to be best practice in terms of packaging and deployment, specifically:
1) Packaging - using the deployTool that comes with iAS6 SP1b to package is a big manual task, especially when you have 200+ jsp files. Are people out there using this or are they scripting it with a build tool such as Ant?
2) Deploying an existing application to multiple iAS's. Are you guys unregistering old application then reregistering new application? Are you shutting down iAS whilst doing the deployment?
3) Deploying ear files can take 5 to 10 mins, is this normal?
4) In a clustered scenario where HTTPSession is shared what are the consequences of doing deployments to data stored in session?
thanks in asvance for your replies
Owen

You may want to consider upgrading your application server environment to a newer service pack. There are numerous enhancements involving the deployment tool and run time layout of your application that make clear where you're application is loading its files from.
If you've at a long running application server environment, with lots of deployments under your belt, you might start to notice slow downs in deployment and kjs start time. Generally this is due to garbage collecting in your iAS registry.
You can do several things to resolve this. The most complete solution is to reinstall the application server. This will guarantee a clean ldap registry. Of course you've got to restablish your configurations and redeploy your applications. When done, backup your application server install space with the application server and directory server off. You can use this backup to return to a known configuation at some future time.
For the second method: <B>BE CAREFUL - BACKUP FIRST</B>
There is a more exhaustive solution that involves examining your deployed components to determine the active GUIDS. You then search the NameTrans section of the registry searching for Applogic Servlet *, and Bean * entries that represent your previously deployed components but are represented in the set of deployed GUIDs. Record these older GUIDs, remove them from ClassImp and ClassDef. Finally remove the older entries from NameTrans.
Best practices for deployment depend on your particular environmental needs. Many people utilize ANT as a build tool. In later versions of the application server, complete ANT scripts are included that address compiling, assembly and deployment. Ant 1.4 includes iAS specific targets and general J2EE targets. There are iAS specific targets that can be utilized with the 1.3 version. Specialized build targets are not required however to deploy to iAS.
Newer versions of the deployment tool allow you to specify that JSPs are not to be registered automatically. This can be significant if deployment times lag. Registered JSP's however benefit more fully from the services that iAS offers.
2) In general it is better to undeploy then redeploy. However, if you know that you're not changing GUIDs, recreating an existing application with new GUIDs, or removing registered components, you may avoid the undeploy phase.
If you shut down the KJS processes during deployment you can eliminate some addition workload on the LDAP server which really gets pounded during deployment. This is because the KJS processes detect changes and do registry loads to repopulate their caches. This can happen many times during a deployment and does not provide any benefit.
3) Deploying can be a lengthy process. There have been improvements in that performance from service pack to service pack but unfortunately you wont see dramatic drops in deployment times.
One thing you can do to reduce deployment times is to understand the type of deployment. If you have not manipulated your deployment descriptors in any way, then there is no need to deploy. Simply drop your newer bits in to the run time space of the application server. In later service packs this means exploding the package (ear,war, or jar) in to the appropriate subdirectory of the APPS directory.
4) If you've changed the classes of objects that have been placed in HTTPSession, you may find that you can no longer utilize those objects. For that reason, it is suggested that objects placed in session be kept as simple as possible in order to minimize this effect. In general however, is not a good idea to change a web application during the life span of a session.

In the Begining it's Flat Files - Best Practice for Getting Flat File Data

I probably should have posed this question here before I delved into writing Java to get data for reports, but better late than never.
Our ERP is written in COBOL. We have a third party ODBC which allows us to access data using a version of SQL. I have several Java sources compiled in my database that access the data and return something relevant. The Java sources are written in a procedural style rather than taking advantage of object oriented programming with attributes and methods.
Now that I am becoming more comfortable with the Java language, I would greatly appreciate any feedback as to best practices for incorporating Java into my database.
My guess is that it would be helpful to model the ERP "tables" with Java classes that would have attributes, which correspond to the fields, and methods to return the attributes in an appropriate way. Does that sound reasonable? If so, is there a way to automate the task of modeling the tables? If not reasonable, what would you recommend?
Thanks,
Gregory

Brother wrote:
I probably should have posed this question here before I delved into writing Java to get data for reports, but better late than never.
Our ERP is written in COBOL. We have a third party ODBC which allows us to access data using a version of SQL. I have several Java sources compiled in my database that access the data and return something relevant. The Java sources are written in a procedural style rather than taking advantage of object oriented programming with attributes and methods.
OO is a choice not a mandate. Using Java in a procedural way is certainly not ideal but given that it is existing code I would look more into whether is well written procedural code rather than looking at the lack of OO.
Now that I am becoming more comfortable with the Java language, I would greatly appreciate any feedback as to best practices for incorporating Java into my database.
My guess is that it would be helpful to model the ERP "tables" with Java classes that would have attributes, which correspond to the fields, and methods to return the attributes in an appropriate way. Does that sound reasonable? If so, is there a way to automate the task of modeling the tables? If not reasonable, what would you recommend?Normally you create a data model driven by business need. You then implement using whatever means seem expedient in terms of other business constraints to closely model that data model.
It is often the case that there is a strong correlation between data models and tables but certainly in my experience it is rare when there are not other needs driven by the data model (such as how foreign keys and link tables are implemented and used.)

Best practice for including additional DLLs/data files with plug-in

Hi,
Let's say I'm writing a plug-in which calls code in additional DLLs, and I want to ship these DLLs as part of the plug-in. I'd like to know what is considered "best practice" in terms of whether this is ok (assuming of course that the un-installer is set up to remove them correctly), and if so, where is the best place to put the DLLs.
Is it considered ok at all to ship additional DLLs, or should I try and statically link everything?
If it's ok to ship additional DLLs, should I install them in the same folder as the plug-in DLL (e.g. the .8BF or whatever), in a subfolder of the plug-in folder or somewhere else?
(I have the same question about shipping additional files too, such as data or resource files.)
Thanks
-Matthew

Brother wrote:
I probably should have posed this question here before I delved into writing Java to get data for reports, but better late than never.
Our ERP is written in COBOL. We have a third party ODBC which allows us to access data using a version of SQL. I have several Java sources compiled in my database that access the data and return something relevant. The Java sources are written in a procedural style rather than taking advantage of object oriented programming with attributes and methods.
OO is a choice not a mandate. Using Java in a procedural way is certainly not ideal but given that it is existing code I would look more into whether is well written procedural code rather than looking at the lack of OO.
Now that I am becoming more comfortable with the Java language, I would greatly appreciate any feedback as to best practices for incorporating Java into my database.
My guess is that it would be helpful to model the ERP "tables" with Java classes that would have attributes, which correspond to the fields, and methods to return the attributes in an appropriate way. Does that sound reasonable? If so, is there a way to automate the task of modeling the tables? If not reasonable, what would you recommend?Normally you create a data model driven by business need. You then implement using whatever means seem expedient in terms of other business constraints to closely model that data model.
It is often the case that there is a strong correlation between data models and tables but certainly in my experience it is rare when there are not other needs driven by the data model (such as how foreign keys and link tables are implemented and used.)

Best practice for dealing with Recordsets

Hi all,
I'm wondering what is best practice for dealing with data retrieved via JDBC as Recordsets without involving third part products such as Hibernate etc. I've been told to NOT use RecordSets throughout in my applications since they are taking up resources and are expensive. I'm wondering which collection type is best to convert RecordSets into. The apps I'm building are webbased using JSPs as presentation layer, beans and servlets.
Many thanks
Erik

There is no requirement that DAO's have a direct mapping to Database Tables. One of the advantages of the DAO pattern is that the business layer isn't directly aware of the persistence layer. If the joined data is used in the business code as if it were an unnormalized table, then you might want to provide a DAO for the joined data. If the joined data provides a subsiduray object within some particular object, you might add the access method to the DAO for the outer object.
eg:
In a user permissioning system where:
1 user has many userRoles
1 role has many userRoles
1 role has many rolePermissions
1 permission has many rolePermissions
ie. there is a many to many relationship between users and roles, and between roles and permissions.
The administrator needs to be able to add and delete permissions for roles and roles for users, so the crud for the rolePermissions table is probably most useful in the RoleDAO, and the crud for the userRoles table in the UserDAO. DOA's also can call each other.
During operation the system needs to be able to get all permissions for a user at login, so the UserDAO should provide a readPermissions method that does a rather complex join across the user, userRole, rolePermission and permission tables..
Note that f the system I just described were done with LDAP, a Hierarchical database or an Object database, the userRoles and rolePermissions tables wouldn't even exist, these are RDBMS artifacts since relational databases don't understand many to many relationships. This is good reason to avoid providing DAO's that give access to those tables.

Best practice for existing target table

Similar Messages

Maybe you are looking for