Baza danych

[Ris]

Witam,
Powstał szkielet bazy danych http://code.google.com/p/linuxadvices/wiki/BazaDanych
jak opisałem w poście wcześniej, za utrzymywanie projektu a w tym
tabel konkretne będą odpowiedzialni osoby przypisane do konkretnej
części projektu. Mimo to zakładam ten wątek w celu dyskusji nad
konkretnymi rozwiązaniami. Od razu mam kilka uwag do istniejącego
projektu bazy.
Tabela Advice
Kolumna "name" to ma być tytuł? Jeśli tak to może zmienić na "title"
Kolumna "modified_at" nie powinna dopuszczać wartości null. Początkowa
wartość powinna być taka sama jak w kolumnie "created_at"
Kolumna "key_words" też nie powinna pozwalać dopuszczać wartości null.
Dodatkowo według mnie powinna być zmiana, bo słów kluczowych może być
więcej do jednej porady. Przenieść słowa kluczowe do nowej tabeli.

--
Robert Sajdok (Ris)

[stallman]

On 2 Sie, 15:38, Ris <robert.saj...@gmail.com> wrote:
> Witam,
> Powstał szkielet bazy danychhttp://code.google.com/p/linuxadvices/wiki/BazaDanych

> jak opisałem w poście wcześniej, za utrzymywanie projektu a w tym
> tabel konkretne będą odpowiedzialni osoby przypisane do konkretnej
> części projektu. Mimo to zakładam ten wątek w celu dyskusji nad
> konkretnymi rozwiązaniami.

Witajcie,
Ja także mam uwagi do modelu bazy danych stworzonej przez Tomka:
1. Brakuje systemu uprawnień dla użytkowników. W funkcjonalnościach
zdefiniowano coś takiego jak stronę administracyjną projektu.
Proponuję stworzenie "profili" uprawnień na zasadzie 3 lub 4 tabel:
(każda z tabel posiada pole id)
profiles:
name, varchar(10), not null
description, text, null

permissions:
name, varchar(10), not null
description, text, null

profiles_permissions:
id_profile, int, not null
id_permission, int, not null

Jeśli użytkownik ma posiadać 1 profil uprawnień w serwisie to
poszerzamy tabelę User o pole - klucz wiążący z tabelą Profiles i
wtedy użytkownik może korzystać tylko z 1 zestawu uprawnień. Jeśli
jednak jeden użytkownik może korzystać z paru profili uprawnień
jednocześnie(temat pod dyskusję) to trzeba utworzyć dodatkową tabelę
wiążącą użytkownika z profilami (relacja jeden do wielu).
Osobiście sądzę że na sam początek 1 profil na użytkownika wystarczy -
pytanie czy będziemy to realizować przez to pole czy przez tablicę
relacji. Sądzę że bardziej przyszłościowe będzie to drugie rozwiązanie
(nie będzie trzeba modyfikować bazy danych).
2. Jeśli od samego początku chcemy budować w miarę optymalne
rozwiązania to pamiętajmy o dodatkowych kolumnach które mają służyć
jako cache. Myślę tu o wszelkiego rodzaju sumach, ilościach komentarzy
(które można przypisać do rady) etc. Ograniczmy narzut jaki może
spowodować np. obliczanie ilości komentarzy i zapisujmy tą ilość
podczas np. dodawania/usuwania komentarza do pola cacheującego.
3. Nie było to chyba omawiane ale czy nie sądzicie że w przypadku rad
przydałoby się coś takiego jak mechanizm wersjonowania rad ? Jest to
przydatne jeśli chcemy śledzić zmiany jakie zaszły w danej poradzie
(jeśli np. ma mieć do niej dostęp wielu użytkowników). W takim
przypadku przydałaby się dodatkowa tabela z kolejnymi wersjami rady.
Nie wiem czy warto robić coś takiego że moderator/założyciel danej
porady może zatwierdzać wersję która wyświetla się użytkownikowi
końcowemu.
4. Tabeli user brakuje 2 pól:
is_active (boolean) default false - Pole które odpowiada za aktywację
użytkownika w serwisie
is_blocked (boolean) default false - Pole które odpowiada za
blokowanie użytkownika
5. Trochę brakuje tej bazie aby spełniać podstawową
funkcjonalność.... Zmiany umieszczać w create.sql oraz nadpisywać plik
wygenerowany przez VP(Visual Paradigm) ? VP będzie obowiązującym
programem czy ustalamy że liczy się tylko to co znajduje się w
create.sql (a VP służy tylko do wizualizacji)?


Pozdrawiam

[Paweł Machowski]

Ja jestem za tym, że możliwość modyfikowania porady powinien mieć tylko jeden użytkownik, po co komuś kilka wersji tej samej porady. Jedyne co może się przydać to np data ostatniej modyfikacji.

W dniu 3 sierpnia 2008 05:45 użytkownik stallman <o...@2mind.pl> napisał:

On 2 Sie, 15:38, Ris <robert.saj...@gmail.com> wrote:

3. Nie było to chyba omawiane ale czy nie sądzicie że w przypadku rad
przydałoby się coś takiego jak mechanizm wersjonowania rad ? Jest to
przydatne jeśli chcemy śledzić zmiany jakie zaszły w danej poradzie
(jeśli np. ma mieć do niej dostęp wielu użytkowników). W takim
przypadku przydałaby się dodatkowa tabela z kolejnymi wersjami rady.
Nie wiem czy warto robić coś takiego że moderator/założyciel danej
porady może zatwierdzać wersję która wyświetla się użytkownikowi
końcowemu.

--
Pozdrawiam
Paweł Machowski

[Tomasz Trela]

On 2008-08-03, at 05:45, stallman wrote:

Ja także mam uwagi do modelu bazy danych stworzonej przez Tomka:

1. Brakuje systemu uprawnień dla użytkowników. W funkcjonalnościach

zdefiniowano coś takiego jak stronę administracyjną projektu.

Proponuję stworzenie "profili" uprawnień na zasadzie  3 lub 4 tabel:

(każda z tabel posiada pole id)

profiles:

name, varchar(10), not null

description, text, null

permissions:

name, varchar(10), not null

description, text, null

profiles_permissions:

id_profile, int, not null

id_permission, int, not null

System profili jest bardzo dobrym pomysłem, zrobiłem update schematu bazy danych, oraz update wiki.

2. Jeśli od samego początku chcemy budować w miarę optymalne

rozwiązania to pamiętajmy o dodatkowych kolumnach które mają służyć

jako cache. Myślę tu o wszelkiego rodzaju sumach, ilościach komentarzy

(które można przypisać do rady) etc. Ograniczmy narzut jaki może

spowodować np. obliczanie ilości komentarzy i zapisujmy tą ilość

podczas np. dodawania/usuwania komentarza do pola cacheującego.

Dobry pomysł, 

3. Nie było to chyba omawiane ale czy nie sądzicie że w przypadku rad

przydałoby się coś takiego jak mechanizm wersjonowania rad ? Jest to

przydatne jeśli chcemy śledzić zmiany jakie zaszły w danej poradzie

(jeśli np. ma mieć do niej dostęp wielu użytkowników). W takim

przypadku przydałaby się dodatkowa tabela z kolejnymi wersjami rady.

Nie wiem czy warto robić coś takiego że moderator/założyciel danej

porady może zatwierdzać wersję która wyświetla się użytkownikowi

końcowemu.

Nie wiem czy to nie za dużo komlikacji. Czy potrzebujemy wersje porad. Jeśli ktoś zmieni poradę (może to zrobić admin i właściciel chya tylko) to oznacza, że poprawione zostały jakieś błędy, czyli stara wersja nie jest dobra, więc nie wiem czy ktoś chce ja jeszcze ogladać. Wprowadzenie wersji porad może spowodować ze użytkownik ma za tagowaną poradę  w wersji nieaktualnej i będzie musial szukać nowej wersji. Mi wydaje się że jest to niepotrzebne, ale można to oczywiście zrobić. 

4. Tabeli user brakuje 2 pól:

is_active (boolean) default false - Pole które odpowiada za aktywację

użytkownika w serwisie

is_blocked (boolean) default false - Pole które odpowiada za

blokowanie użytkownika

Dodane

5. Trochę brakuje  tej bazie aby spełniać podstawową

funkcjonalność.... Zmiany umieszczać w create.sql oraz nadpisywać plik

wygenerowany przez VP(Visual Paradigm)  ? VP będzie obowiązującym

programem czy ustalamy że liczy się tylko to co znajduje się w

create.sql (a VP służy tylko do wizualizacji)?

No jako baza danych produkcyjna to pewnie się nie nadaje, ale do pracy czemu nie? Zaraz opiszę na wiki jak roziwązać problem wileu konfiguracji bazy daanych.

Jeśli chodzi o VP, to użyłem go bo mam po prostu ten program i nie mam możliwości korzystać z np. Visual Visio, bo nie mam Windows. 

Usunałem także te pliki z działu download. Pliki za to dodałem do svn do katalogu database/schemat. Dzięki temu będzie łatwiej robić zmiany i pliki na wiki są wyświetlane bezpośrednio z svn.

Jesli chodzi o modyfikacje to wydaje mi się ze kazda zmiana musi być w skrypcie sql i pliku vp. 

Wtedy na wiki i kodzie mamy to samo, czyli aktualną wersję. 

Export na wiki jest bardzo szybki. Otwierasz plik  vp, dajesz export do pliku, nadpisujesz plik schemat.jpg.

Dajesz svn ci (dwa pliki zmodyfikowane (vp i jpg) i na wiki obrazek jes juz aktualny.

Zacząlem update WIKI

Pozdrawiam

Tomasz Trela

[Tomasz Trela]

Przeczytałem co napisałem i wydaje mi się troszkę chaotyczne.

Proszę napiszcie swoje uwagi na temat wiki i tego co napisałem i postaram się dokładniej sprecyzować swoje myśli.

Jeśli coś jest nie jasne lub macie inne pomysły to piszcie.

Pozdrawiam

Tomasz Trela

[Robert Sajdok]

2008/8/3 Tomasz Trela <pikso...@gmail.com>

Też wydaje się mi, że wersjo wanie porad to za duża komplikacja. Jeśli ktoś znajdzie pomysł na rozwiązanie problemu w inny lepszy sposób, to po prostu stworzy nową poradę.
 

4. Tabeli user brakuje 2 pól:

is_active (boolean) default false - Pole które odpowiada za aktywację

użytkownika w serwisie

is_blocked (boolean) default false - Pole które odpowiada za

blokowanie użytkownika

Dodane

5. Trochę brakuje  tej bazie aby spełniać podstawową

funkcjonalność.... Zmiany umieszczać w create.sql oraz nadpisywać plik

wygenerowany przez VP(Visual Paradigm)  ? VP będzie obowiązującym

programem czy ustalamy że liczy się tylko to co znajduje się w

create.sql (a VP służy tylko do wizualizacji)?

No jako baza danych produkcyjna to pewnie się nie nadaje, ale do pracy czemu nie? Zaraz opiszę na wiki jak roziwązać problem wileu konfiguracji bazy daanych.

Jeśli chodzi o VP, to użyłem go bo mam po prostu ten program i nie mam możliwości korzystać z np. Visual Visio, bo nie mam Windows. 

Apeluje o używanie narzędzi darmowych, bo nie każdego stać na rozwiązania płatne a piractwa szerzyć nie chcę :)
 

Usunałem także te pliki z działu download. Pliki za to dodałem do svn do katalogu database/schemat. Dzięki temu będzie łatwiej robić zmiany i pliki na wiki są wyświetlane bezpośrednio z svn.

Jesli chodzi o modyfikacje to wydaje mi się ze kazda zmiana musi być w skrypcie sql i pliku vp. 

Wtedy na wiki i kodzie mamy to samo, czyli aktualną wersję. 

Export na wiki jest bardzo szybki. Otwierasz plik  vp, dajesz export do pliku, nadpisujesz plik schemat.jpg.

Dajesz svn ci (dwa pliki zmodyfikowane (vp i jpg) i na wiki obrazek jes juz aktualny.

Jeszcze kwestia OR mappera. Jego wybór i generowanie. Trzeba pomyśleć, żeby potem nie trzeba było plików mapujących do Hibernate czy JPA robić ręcznie. Wiem, że da się  to robić z automatu ale nie miałem okazji, może ktoś ma doświadczenie?

--
Robert Sajdok (Ris)

[stallman]

On 4 Sie, 11:18, "Robert Sajdok" <robert.saj...@gmail.com> wrote:
> Apeluje o używanie narzędzi darmowych, bo nie każdego stać na rozwiązania
> płatne a piractwa szerzyć nie chcę :)

Z darmowych rozwiązań do modelowania bazy danych przychodzi mi Kexi -
nie wiem czy jest dostępny za darmo skompilowany pod Windows (ale ten
problem pewnie tylko mnie dotyczy :).
Pamiętam że Eclipse posiadał darmowe wtyczki od takich rzeczy ;)
dzisiaj zrobię research i podeślę tutaj i wybierzemy odpowiadające
wszystkim rozwiązanie.
Jeśli chodzi o mnie to może to być czysty sql dostosowany do standardu
SQL.

> Jeszcze kwestia OR mappera. Jego wybór i generowanie. Trzeba pomyśleć, żeby
> potem nie trzeba było plików mapujących do Hibernate czy JPA robić ręcznie.
> Wiem, że da się  to robić z automatu ale nie miałem okazji, może ktoś ma
> doświadczenie?

Pewnie otwieram starą dyskusję ale biorąc pod uwagę że pierwsza wersja
projektu ma być szkoleniowa i lekka to czy jest sensowne abyśmy
zaciągali do tego jakiegoś rozbudowanego ORM? Mi to obojętne ale nie
wiem czy to nie zaburzy tempa (za dużo rzeczy naraz) nauki i czy nie
lepiej byłoby zacząć od prostego JDBC a dopiero później zaciągać do
bazy danych Hibernate ?


Pozdrawiam

[Robert Sajdok]

2008/8/4 stallman <o...@2mind.pl>

Witam,
Kwestia ORM jest bardzo prosta i raczej powoduje, że tworzy się szybciej i prościej aniżeli miało by to utrudniać. Mam na myśli proste mapowanie tabel do CRUD, czyli edycja, dodawanie wyświetlanie danych.


--
Robert Sajdok (Ris)