[php, mysql] projektowanie bazy danych

0

Witam,
mam do zrobienia strone internetową z rozkładem jazdy dla małego lokalnego przewoźnika autobusowego. przedsiębiorstwo jest małe ale rozwija się bardzo szybko, już ma kilka linii uruchomionych a ort! będzie kilkanaście dlatego zarządali sobie łatwej w aktualizacji strony z rozkadem jazdy. ort! PHP i MySQL jest tutaj oczywiste. znam sie co nieco na php, ale problem moze stanowić zaprojektowanie porządnej bazy danych. myslałem o czyms podobnym do stron:

http://rozklady.com.pl/main.php?page=polo&ind=1
http://pks.bydgoszcz.pl/wyszukiwarka.php

obowiazkowe elementy to wyszukiwarka (czas odjazdu, przyjazdu, długość trasy, oznaczenia rodzaju połączenia) i tabliczki przystankowe.

prezentacja danych to pikus, najważniejsza jest DOBRA BAZA. liczę na wasze pomysły. dzięki!
(ale sie rozpisałem :) )

0

w jakiej formie masz dane - czas postoju na każdym przystanku czy czas startu + czas w jakim odległość między a i b jest pokonywana?

0

mam czas startu + czas w jakim odległość między a i b jest pokonywana + odleglosci w km + cena biletu

0

no to tak

  1. tabela przystanków
    id | nazwa | co tam jeszcze chcesz
  2. tabela trasa nazwa
    id | nazwa | co tam jeszcze chcesz
  3. tabela trasa przystanki
    id | id_trasy | numer | id_przystanku | co tam jeszcze chcesz
  4. tabela odległości
    id | przystanek_id_od | przystanek_id_do | czas | km | opłata | co tam jeszcze chcesz

dodatkowo możesz jeszcze mieć tabelę busów i kierowców i też je do tras przypisać

taka organizacja jw daje Ci

  1. proste wyszukanie (i poukładanie) przystanków dla trasy x (w jedną bądź drugą stronę
  2. proste wyszukanie wszystkich tras, które obsługują dany przystanek
  3. policzyć czas (kilometry, opłatę) dla tras "jeżdzących" od A do B i przechodzących przez C, D, ... (w sumie, czy dla każdej z osobna)
  4. proste szukanie tras z A do B i startujących o lub przyjeżdżających o
0
Autobus666 napisał(a)

PHP i MySQL jest tutaj oczywiste.

Wcale nieoczywiste. Ile userów planujesz? Jak duża baza?
Jeśli to jedna, czy dwie linie autobusowe, to ujdzie.
Jeśli kilkanaście, współczuję userom tego systemu, którzy będą czekać pół godziny na wyniki wyszukiwania, oraz developerom, którzy go później będą pielęgnować (chyba że jesteś jakimś killerem PHP i robisz kod lepszy niż przeciętny, ale wtedy raczej też by nie rozważał PHP).
Takie systemy generalnie robi się w Java Enterprise i na mocniejszych bazach niż MySQL.

0
Krolik napisał(a)

Wcale nieoczywiste. Ile userów planujesz? Jak duża baza?
Jeśli to jedna, czy dwie linie autobusowe, to ujdzie.
Jeśli kilkanaście, współczuję userom tego systemu, którzy będą czekać pół godziny na wyniki wyszukiwania, oraz developerom, którzy go później będą pielęgnować (chyba że jesteś jakimś killerem PHP i robisz kod lepszy niż przeciętny, ale wtedy raczej też by nie rozważał PHP).
Takie systemy generalnie robi się w Java Enterprise i na mocniejszych bazach niż MySQL.

ROTFL :-D :-D :-D

0
Misiekd napisał(a)

ROTFL :-D :-D :-D

ROTFLem są goście, którzy "potrafią trochę programować w PHP", zadają pytania na forum "jak zrobić bazę", PHP jest dla niech jedyne i "oczywiste", a chcą napisać soft, który będzie używany (jak się domyślam) przez wielu ludzi i będzie wpływał na wizerunek wcale-nie-tak-małej firmy.

Jeśli to ma być prototyp napisany w 2 dni na kolanie, który jedynie wyświetla statyczne informacje o rozkładzie jazdy wyciągnięte z bazy danych, to spoko, PHP jest tu najlepszym rozwiązaniem.
Tylko widziałem w życiu sporo takich systemów, które później się rozrastały, bo klient chciał jeszcze to i śmo, i po chwili zamiast zgrabnych 5 skryptów powstawał gigantyczny, nieczytelny i pełen błędów system składający się z kodu HTML przeplatanego PHP z wywolaniami SQL, wzbogacanego gdzieniegdzie JS i wspomaganego skryptami w Perlu wywoływanymi z Crona.

Powiesz, że to jest wina programisty, a nie technologii - racja, ale jak weźmiesz dobrego programistę (znającego dobrze różne technologie i języki programowania), dasz mu wybór technologii i odpowiedni budżet, ale postawisz twarde wymagania na funkcjonalność, jakość i czas wykonania, to wykona to w C#/Javie/Rubym + Oracle (lub w wersji niskobudżetowej DB/2 lub w wersji super niskobudżetowej PostgreSQL) a nie w PHP + MySQL. Nawet w przypadku samego prototypu zastanawiałbym się nad wyborem Ruby on Rails kotra PHP. Po prostu te alternatywne technologie oferują znacznie więcej i jeśli kogoś nie ogranicza własny nieprofesjonalzm, decyzja szefa lub możliwości hostingowe, to po co się męczyć? Wolisz jeździć tanim samochodem czy dobrym samochodem?

0

Krolik, ale moment, są dobrzy programiści PHP i są źli programiści PHP, są dobre zasady pisania w PHP i są złe. Dobrzy ludzie od PHP nie przeplatają kodu XHTML z PHP, SQL jest zwykle tylko na wywołaniach procedur składowanych. XHTML jest rozdzielony od CSS, a JS tworzy warstwę zachowania. Takich produktów jest malutko, ale ich styl jest piękny ;) Ale cholernie mało jest ludzi, którzy umieją takie coś zrobić.

Ruby On Rails jest owszem, fajne, a czy widziałeś jak sprawuje się w zastosowaniach pod obciążeniem? Średnio.

A czy widziałeś powstałe na RoRowej modzie na MVC frameworki dla PHP w rodzaju PHP on Trax, CodeIgnitera czy świetnego Cake? Naprawdę, PHP już nie jest językiem dla nastolatków (pierwotnie napisałem nastolatek, ale nastolatki używają blog.onet.pl, a nie piszą w PHP ;)) piszących 5 skryptów do forum i liczenia odwiedzin.

A przepraszam takie Allegro to denny serwis (nie bierzemy pod uwagę zabezpieczeń!), który przez swoje PHP jest tragiczny i trzeba czekać pół godziny na wyniki wyszukiwania? Jakoś jest napisany w PHP i żyje. Aczkolwiek z Oracle, a nie z MySQL, ale za to bez J2EE.

Aczkolwiek chyba zeszliśmy na Off-Topic mały.

0
Ktos napisał(a)

Krolik, ale moment, są dobrzy programiści PHP i są źli programiści PHP, są dobre zasady pisania w PHP i są złe. Ale cholernie mało jest ludzi, którzy umieją takie coś zrobić.

Takich ludzi jest zapewne więcej, ale zwykle nie programują w PHP, chyba że muszą.

Ruby On Rails jest owszem, fajne, a czy widziałeś jak sprawuje się w zastosowaniach pod obciążeniem? Średnio.

PHP też średnio. Wydajnosć obu interpreterów jest podobna. Kilkadziesiąt razy mniejsza niż rozpędzona Java/.NET. Ale nie jest to jakiś wielki problem bo zwykle całą robotę odwala baza danych - napisana w C/C++.

A czy widziałeś powstałe na RoRowej modzie na MVC frameworki dla PHP w rodzaju PHP on Trax, CodeIgnitera czy świetnego Cake?

Widziałem i doceniam, że sporo zmienia się na lepsze. Problem w tym, że bardzo daleko im do np. Spring + Tapestry + Hibernate, zarówno pod względem funkcjonalności jak i szybkości działania. Ciekawe jak realizują buforowanie obiektów w pamięci POMIĘDZY wywołaniami http, kiedy skrypt PHP żyje na czas jednego wywołania? Poza tym im więcej warstw aplikacji jest napisane w PHP (jako framework), tym wolniej to wszystko chodzi. Zaraz okaże się, że jest potrzebny JIT oraz dobry garbage collector, dorzucą jeszcze namespace'y i... wyjdzie z tego już prawie Java :|

(nie bierzemy pod uwagę zabezpieczeń!)

Czemu? [diabel]

Aczkolwiek chyba zeszliśmy na Off-Topic mały.

No tak, to dyskusja bardziej do działu inżynieria oprogramowania.
Chciałem tylko pokazać, że istnieją też inne drogi, a kwestia wyboru nie jest taka prosta, jak się autorowi posta wydaje.

Dlatego wracając do oryginalnego tematu, uważam, że napisanie dobrej wyszukiwarki połączeń dla kilkunastu linii autobusowych przecinających się pewnie w kilku punktach nie jest tak trywialne jak wyszukiwanie listy aukcji należących do usera Z, czy kończących się o zadanej godzinie albo wyszukanie produktu po słowach kluczowych. Nie da się tego zrobić jednym czy kilkoma zapytaniami SQL. Zagadnienie wymaga całkiem niezłego kawałka logiki biznesowej (Dijkstra, A*?) działającego na obiektach z bazy danych. Dodatkowym problemem jest to, że znalezienie tego jednego połączenia może pociągać konieczność odczytu sporej części informacji z bazy. Łatwej jest to napisać mając silny i szybki język (C#/Java) z dobrym frameworkiem O/R załatwiającym sprawy buforowania obiektów (cache) i optymalizującym zapytania przez np. outer-join-fetching, niż kodując to wszystko na ręcznych SQLach, jak to zwykle bywa w PHP. Nie mówiąc o tym, że w PHP buforowanie obiektów między zapytaniami bedzie dużym problemem (a buforowanie stron przwez np. squida nic nie da, bo raczej każdy będzie szukał czegos innego).

0

to ja jeszcze odnośnie mojego ROTFLa wyżej. Nie odnosił się on do tego, że coś tam jest lepsze lub gorsze tylko do stwierdzenia, że w PHP i MySQLu się nie da - da się i to całkiem sprytnie będzie chodzić. Jedynie czy pytacz da radę. Jeśli chodzi o samego MySQLa to przy dużej ilości zapytań wybierających dane jest praktycznie najszybszy z baz daromwych. I to jest fakt. Oczywiście jeśli chodzi o całość jako serwer SZBD to MySQL wcale nie jest taki super, hiper zajebisty.

Druga sprawa - PHP. Przecież to ma być tylko prezentacja danych.

Krolik napisał(a)

uważam, że napisanie dobrej wyszukiwarki połączeń dla kilkunastu linii autobusowych przecinających się pewnie w kilku punktach nie jest tak trywialne jak wyszukiwanie listy aukcji należących do usera Z, czy kończących się o zadanej godzinie albo wyszukanie produktu po słowach kluczowych. Nie da się tego zrobić jednym czy kilkoma zapytaniami SQL. Zagadnienie wymaga całkiem niezłego kawałka logiki biznesowej (Dijkstra, A*?) działającego na obiektach z bazy danych. Dodatkowym problemem jest to, że znalezienie tego jednego połączenia może pociągać konieczność odczytu sporej części informacji z bazy. Łatwej jest to napisać mając silny i szybki język (C#/Java) z dobrym frameworkiem O/R załatwiającym sprawy buforowania obiektów (cache) i optymalizującym zapytania przez np. outer-join-fetching, niż kodując to wszystko na ręcznych SQLach, jak to zwykle bywa w PHP. Nie mówiąc o tym, że w PHP buforowanie obiektów między zapytaniami bedzie dużym problemem (a buforowanie stron przwez np. squida nic nie da, bo raczej każdy będzie szukał czegos innego).

z tym, że pewnie nie słyszałeś o procedurach wbudowanych, widokach i innych "bajerach", któe mają normalne SZBD. Dla mnie zaszywanie logiki biznesowej w warstwie prezentacji to pomyłka. Jeśli nie stawiamy osobnego oprogramowania, które zajmuje się tylko i wyłącznie logiką biznesową to wstawiamy ją do bazy - co by nie mówić, w czym by nie pisać to jednak LB zaszyta w bazie (procedury składowe, wyzwalacze, widoki, UDFy) jest i będzie zawsze najszybsza bo ma dane "bezpośrednio od dostawcy" i nie ma wąskiego gardła typu sieć (baza i LB na różnych kompach), TCP (połączenie przez sockety) czy np. dlle (jeśli dostęp jest natywny)

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0