Názvové konvence

2012-03-21 Komentáře vypnuty

Existuje několik různých doporučení jak pojmenovávat databázové objekty. Nezáleží však zda je použijeme nebo si vytvoříme vlastní, nejdůležitější je se jimi pevně řídit v celém projektu, protože nám usnadňují orientaci v databázovém systému. Tady je jedno z nich:

  • obecné
    • jednotné číslo
    • velká písmena
    • oddělení slov pomocí podtržítka: _
    • zkratky jen v případech, kdy je text delší než 30 znaků (nechat rezervu pro případ doplnění různých přípon)
  • Tabulky
    • název založený na jméně entity (dostatečně výstižný)
    • názvy v rámci projektu jedinečné (v případě, že projekt používá více databází)
    • nepoužívat obecné názvy jako soubor, tabulka apod.
    • nepoužívat geografické názvy apod. (lépe nad všemi daty vytvořit view EMPLOYEE_EU_VW)
  • Sloupce
    • používat název tabulky jako prefix pouze a hlavně u primárního klíče (EMPLOYEE_ID)
    • cizí klíč pojmenovat přesně podle názvu odpovídajícího sloupce primárního klíče
  • Omezení
    • TNAME_TYP_CNAME,
      • TNAME: název tabulky
      • TYP: PK | FK | UQ | CK (omezení typu check)
      • CNAME: název sloupce (sloupců), nad nímž je omezení definováno
  • Indexy
    • TNAME_TYP_CNAME
      • TNAME: název tabulky
      • TYP: UX (jedinečný index) |IX (nejedinečný index)
      • CNAME: název sloupce (sloupců), nad nímž je omezení definováno
  • Pohledy
    • NAME_VW
      • NAME: název nejdůležitější podkladové tabulky a volitelně i nějaký smysluplný text
    • název by měl smysluplně popisovat účel: EMPLOYEE_EU_VW

Source:

  • Andrew Oppel: Databáze bez předchozích znalostí
Rubriky:Databáze

Nastavení a struktura Maven projektu

2012-03-14 Komentáře vypnuty

Stažení a nastavení Maven:

  • stáhni a rozbal Maven 2/3
  • nastav M2_HOME & Path v systému |Maven in 5 minutes|
  • v M2_HOME\conf\settings.xml nastav <localRepository>

Základní struktura Maven projektu může vypadat takto:

A tady je základní Maven konfigurák pom.xml:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
         http://maven.apache.org/xsd/maven-4.0.0.xsd">

    <modelVersion>4.0.0</modelVersion>

    <groupId>com.wordpress.kamiluv</groupId>
    <artifactId>web-app</artifactId>
    <version>0.1-SNAPSHOT</version>
    <packaging>war</packaging>

    <name>WebApp</name>
    <url>https://kamiluv.wordpress.com</url>
    <description>Some web application.</description>

    <properties>
    </properties>

    <build>
        <plugins>
            <!-- Set Java version, default is 1.3 -->
            <plugin>
                <artifactId>maven-compiler-plugin</artifactId>
                <configuration>
                    <source>1.7</source>
                    <target>1.7</target>
                </configuration>
                <version>2.3.2</version>
            </plugin>
            <!-- Newer maven plugin for working with Java 7 -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-war-plugin</artifactId>
                <version>2.1.1</version>
            </plugin>
        </plugins>
    </build>

    <dependencies>
    </dependencies>

    <repositories>
    </repositories>

</project>

Na závěr nastavení Source a Test složek v IntelliJ Idea:

Folder setting in IntelliJ Idea

Rubriky:IntelliJ IDEA, Maven

Číselné typy v Javě a SQL

2012-03-13 Komentáře vypnuty
int, long & NUMBER

One paranoid delusional fear that programmers frequently have is running out of sequence numbers. Since most sequence strategies just keep incrementing a number it is unavoidable that you will eventually run out. However as long a large enough numeric precision is used to store the sequence id this is not an issue. For example if you stored your id in a NUMBER(5) column, this would allow 99,999 different ids, which on most systems would eventually run out. However if you store your id in a NUMBER(10) column, which is more typical, this would store 9,999,999,999 ids, or one id each second for about 300 years (longer than most databases exist). But perhaps your system will process a lot of data, and (hopefully) be around a very long time. If you store your id in a NUMBER(20) this would be 99,999,999,999,999,999,999 ids, or one id each millisecond for about 3,000,000,000 years, which is pretty safe.

But you also need to store this id in Java. If you store the id in a Java int, this would be a 32 bit number , which is 4,294,967,296 different ids, or one id each second for about 200 years. If you instead use a long, this would be a 64 bit number, which is 18,446,744,073,709,551,616 different ids, or one id each millisecond for about 600,000,000 years, which is pretty safe.

  • int (32 bit number, 4,294,967,296 different ids) ≈ NUMBER(10)
  • long (64 bit number, 18,446,744,073,709,551,616 different ids) ≈ NUMBER(20)
 
Source:
NUMBER vs. VARCHAR2

Q: When should I use NUMBER and when should I use VARCHAR2?

A: If you need to perform mathematical operations on a value, use NUMBER. If you are not doing math (or if the values are not used as mathematical values), store the value in a VARCHAR2.

Example: You have a data warehouse and you store an account number and a sale price. Sale price may be added or multiplied so it is NUMBER. Account number may be all numeric digits but it makes no sense to perform mathematical operations against it. Store account number as VARCHAR2.

Even if your application will not perform math against the sale price, store it as NUMBER because it makes sense to perform math against it. This is pretty much a common sense thing to me.

There is always an exception. Surrogate keys (as in sequences) – store them as a NUMBER. While you won’t be adding and subtracting them, there are benefits to storing them as a NUMBER. For one thing, you will not have to convert from numeric (result of a sequence) to string to store them.

Source:
Rubriky:Databáze, Java

Úrovně výjimek Log4J

2012-03-12 Komentáře vypnuty

TRACE
Nejnižší úroveň, obvykle vypisujeme pouze do souboru. Vhodné pro různé check-pointy (metoda zavolána, různé počítadla pro ladící účely). Tato úroveň může obsahovat mnoho zpráv, často je programátory nevyužívána a je psáno zbytečně mnoho informací do úrovně DEBUG.

DEBUG
Ladící hlášky, které pomáhají zákazníkovi identifikovat prvotní problém, případně vytvořit report pro dodavatele, aby mohl chybu opravit. V DEBUG by nemělo být příliš hlášek, ale zároveň by tato úroveň měla poskytovat dostatek informací k tomu, aby mohlo být zpětně zjištěno, v čem je problém.

INFO
Hlášky INFO obvykle nejsou vypisovány ve standardní instalaci, ale zákazník si může zvýšit vypisování z WARN na INFO a měl by vidět o něco více informací. Hlášky INFO jsou vhodné zejména pro různé informační zprávy typu něco se startuje, server znovu načetl konfiguraci nebo že aplikace načítá soubor z disku.

WARN
Tato úroveň by měla být zapnuta v implicitní instalaci softwaru, program informuje o události, která není obvyklá. Příklad – potřebná konfigurační hodnota nebyla nalezena v konfiguraci, program použije   defaultní hodnotu. Je vždy dobré se zamyslet, jestli daná je daná hláška chybou (ERROR), varováním (WARN) nebo dokonce pouze informativního charakteru (INFO).

ERROR
V aplikaci došlo k chybovému stavu, který však nenaruší běh programu. Typicky například nemohl být zpracován požadavek na serveru kvůli špatné konfiguraci nebo třeba chyba vstupních dat – program neprovede svoji činnost, ale čeká na další (validní) vstup.

FATAL
Došlo k vyjímečnému stavu a program ukončuje svoji činnost. Například soubor nebyl vůbec nalezen, chyba v programu nebo došla paměť.

Rubriky:Java, Logging

Code Conventions at Oracle

2012-03-12 Komentáře vypnuty

Původní SUNovské Java Code Conventions jsou nyní na Oracle stránkách. I když poslední verze pochází z roku 1999 a mnoho věcí za nás řeší IDE, jsou stále platné a každý programátor by je měl zkouknout a mít v povědomí:

Rubriky:Code Review