пропозиції роботи
Wypowiedzi
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy biuro podróży
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy biuro podróży
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy biuro podróży
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy biuro podróży
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy biuro podróży
-
Czyżby nadchodzące wybory już przyniosły nowy podział administracyjny kraju...
-
Wojciech T.:
Z wymagań Jarka Tkaczyka to nie wynika, a jest wręcz przeciwnie:
[...]
Głównym celem tej tabeli jest wyświetlanie użytkownikowi historii zmian, więc śmiem twierdzić, że tabela będzie dość często odpytywana. Chyba, że nie mam racji i zapytania będą sporadyczne. Wtedy zgoda. Można się pokusić o trzymanie wszystkiego "w jednym worku", lecz w przypadku gdy np. 10 użytkowników naraz zacznie sobie śledzić zmiany na rekordach, to może zrobić się dość nieciekawie :)
Z moich wymagań zawartych w krótkim zdaniu można różne wnioski wyciągać, więc już piszę konkretniej.
Otóż w rzeczy samej chodzi o małą bazę, stosunkowo niewiele rekordów i sporadyczne przeglądanie historii, przy czym użytkowników jednocześnie odpytujących bazę może być w porywach 2-3.
Zatem główną kwestią, jak chciałem poruszyć, to wygoda pracy na archiwum, wydajność tutaj nie stanowi problemu. -
Dawid Rokita:
Panowie, nie rozkminiliście wariantu następującego :-)
Stosując wasz sposób w poniższym przykładzie nie wiemy czy kraj_id = 1 powinien być aktualizowany do 2 czy według starej wersji. Nie wiem czy dobrze wyjaśniłem ale mam nadzieję że rozumiecie.
Cóż Dawid, jeśli dobrze rozumiem twoje intencje w pierwszym zdaniu, to id pozostaje 'stare'.
Niemniej jednak ty wytaczasz działo armatnie tam, gdzie ja chcę ubić muchę!
Nie o to chodzi :) -
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy biuro podróży
-
Dzięki za rady, brałem pod uwagę między innymi jedną tabelę i grupowanie rekordów, właśnie ze względu na niewielkie rozmiary bazy, ale jak to w życiu bywa, może się okazać (i oby tak było), że szybko urośnie.
Tak więc myślę jednak o rozwiązaniu z osobną tabelą archiwalną + trigger dodający wpisy przy update tabeli głównej.
Teraz zastanawiam się nad jednym: jako że główna ma kilka kluczy obcych do tabel pomocniczych, czy lepiej pozostawić ten sam układ, czy też w archiwalnej wpisać wszystko statycznie?
Zasadniczo Archiwum nie ulega zmianie, więc raczej wersja nr 2, ale może macie inną sugestię?Jarek Tkaczyk edytował(a) ten post dnia 03.11.10 o godzinie 23:56 -
MySQL, mała baza: tabela z niewielką ilością rekordów (do kilku tys.) + kilka tabel pomocniczych z maks kilkunastoma pozycjami.
W jaki sposób najlepiej wykonać funkcjonalność historii zmian w bazie, przy czym głównym celem jest wyświetlenie użytkownikowi kolejnych wersji, a nie logi poszczególnych zmian?
Tak by można było porównać kolejne wersje i uwidocznić zmienione dane (parami wersja X i wersja X+1).Jarek Tkaczyk edytował(a) ten post dnia 03.11.10 o godzinie 17:23 -
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy ABY POMÓC W 48 GODZIN
-
Piotr Krajewski:
super działa :) a jak to wygląda w przypadku gdy mam wspolrzedne geograficzne lat i lng ? tez mozna jakość na podstawie tych danych okreslić zoom?
Masz jeden punkt latLng czy więcej?
Jeśli jeden to wykorzystasz coś z map.panTo/setCenter/setZoom w zależności od potrzeb.
Jeśli komplet punktów latLng i chcesz, żeby wszystkie były widoczne to robisz z nich obiekt latLngBounds i dopasowujesz do niego map.fitBounds/panToBounds.Jarek Tkaczyk edytował(a) ten post dnia 31.10.10 o godzinie 21:27 -
Piotr Krajewski:
Witam wszystkich,
mam pytanie odnosnie dynamicznego przyblizenia w zależnośco od znalezionych wyników. Np. podaje w formularzu samo wojewodztwó to mapa wskazuje ustawia się na zoom np. 8 jesli mam miasto i ulice wtedy zoom ustawia się np. na 12. Z tymże nie chcę robić switcha w zależności od tego co wpisałem , gdyż gdzieś widziałem że zoom był automatycznie liczony wg jakiegoś wzoru na podstawie zwróconych danych z mapy. Moje pytanie brzmi jak takie coś osiągnąć ? ewentualnie jak wy macie to rozwiązane ??
API 3 robi to za ciebie zasadniczo - próbowałeś http://code.google.com/intl/pl/apis/maps/documentation...?
Wystarczy dopasować mapę do geokodowania, w najprostszej wersji dla pierwszego wyniku:
map.fitBounds(results[0].geometry.viewport);
Jeśli to ci nie wystarczy daj znać. -
Łukasz Peta:
zadziałało,dzięki:)
są jakieś konwertery do api3??:)
Zacząć można od tego http://www.google.com/intl/pl/events/io/2010/sessions/...
A odpowiadając - nie spotkałem się. -
Łukasz Peta:
Bo firefox jest ścisły w tej materii i podobnie jak dla mnie updateobiektu === undefined.
więc zdefiniuj var updateobiektu = document.updateobiektu; w load() i gitara.
A swoją drogą łatwiej pracuje się w API3, jeśli tworzysz coś nowego, to polecam. -
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Projekty start-up
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Projekty start-up
-
Jędrzej Jeziorowski:
Dzięki za ofertę! Na pewno jeśli nie bede sobie radził to sie zgłoszę.
Póki co świetne rozwiazanie znalazłem na stronie http://www.google.com/support/forum/p/maps/thread?tid=...
Trochę "na piechotę" metoda, ale ważne że działa!
Jeśli zależy ci tylko i wyłącznie na wyświetleniu danych, to możesz jak najbardziej na piechotę, choć lepiej trochę pobawić się w API zamiast na piechotę i skorzystać z warstwy kml jak pisał Michał.
Minusem tej metody jednak jest to, że wszystko masz hurtem wyłożone na mapę jako jeden obiekt, co oznacza, że nie możesz wykorzystywać poszczególnych linii, markerów ani innych obiektów. Zatem jeśli przyjdzie ci ochota na edycję tych danych na swojej mapie, to już nie wystarczy KmlLayer. -
Agnieszka C.:
Przeczuć wszystko na wordpressa i sprawa załatwiona.
Dołącz do GoldenLine
Oferty pracy
Sprawdź aktualne oferty pracy
Aplikuj w łatwy sposób
Aplikuj jednym kliknięciem
