In SQL Developer 3, this is very straight forward;
View > Data Modeler > Browser.
The browser will show up as one of the tabs along the left-hand side.
Click on the Browser tab, expand the design, right-click Relational Models and select 'New Relational Model'.
Then just drag the tables you want onto the model.
To save/export the diagram to a PDF do;
File > Data Modeler > Print Diagram > PDF
Follow instructions to finish
happy modelling
Mabura Ze Guru
Experiences of an OpenSource developer.. "Everyday trying to get closer to the metal".
Tuesday, May 7, 2013
Monday, May 6, 2013
Friday, May 3, 2013
TRUE/REAL data pagination
I was recently implementing Lazy Loading in Primefaces
One of the insights i would like to share is that real efficient pagination is achieved by fetching data from the database (backend) in chunks as opposed to loading everything in memory.
This saves both bandwidth and memory (client side).
The trick here is to use OFFSET and LIMIT sql clauses in conjuction with ORDER BY.
Example 1: Returning the first 100 rows from a table called employee:
SELECT employee_id, employee_name, remarks FROM employee ORDER BY employee_id ASC LIMIT 100;
Example 2: Returning 10 rows from the table employee starting at row 15
SELECT employee_id, employee_name, remarks FROM employee ORDER BY employee_id ASC OFFSET 15 LIMIT 10;
Monday, April 29, 2013
LMFAO - Looking Manualy for Abnormal Output
Dont use System.out() for debugging a serious java app. Use logs(runtime) and JUnit for testing.
The best explanation is (from a StackOverflow thread)
Question(part):
"Whether I write simple applications or larger ones I test them with the
System.out statements and it seams quite easy to me. " and on he goes asking whay he should use JUnit.Answer(part):
That's not testing, that's "looking manually at output" (known in the biz as LMAO). More formally it's known as "looking manually for abnormal output" (LMFAO).
Any time you change code, you must run the app and LMFAO for all code affected by those changes. Even in small projects, this is problematic and error-prone.
Now scale up to 50k, 250k, 1m LOC or more, and LMFAO any time you make a code change. Not only is it unpleasant, it's impossible: you've scaled up the combinations of inputs, outputs, flags, conditions, and it's difficult to exercise all possible branches.
Worse, LMFAO might mean visiting pages upon pages of web app, running reports, poring over millions of log lines across dozens of files and machines, reading generated and delivered emails, checking text messages, checking the path of a robot, filling a bottle of soda, aggregating data from a hundred web services, checking the audit trail of a financial transaction... you get the idea. "Output" doesn't mean a few lines of text, "output" means aggregate system behavior.

Lastly, unit and behavior tests define system behavior. Tests can be run by a continuous integration server and checked for correctness. Sure, so can
System.outs,
but the CI server isn't going to know if one of them is wrong–and if it
does, they're unit tests, and you might as well use a framework.No matter how good we think we are, humans aren't good unit test frameworks or CI servers.
Source StackOverflow
Friday, April 19, 2013
Conditional Triggers in Postgres
Since version 9.0 we can execute triggers conditionaly
Example
CREATE TRIGGER trGenerateSchedule
AFTER INSERT OR UPDATE OF is_confirmed ON job_location
FOR EACH ROW
WHEN (NEW.is_confirmed = true)
EXECUTE PROCEDURE generateSchedule();
This is a column trigger that listens for a change (to true) of a single column in the job_location table
Subscribe to:
Posts (Atom)