Witamy na La Rambla, gdzie dyskusje toczą się całą dobę! La Rambla to dział stworzony specjalnie dla zarejestrowanych Użytkowników FCBarca.com. Zapraszamy do rejestracji oraz dyskusji nie tylko o Barcelonie i nie tylko o piłce nożnej. W tym dziale obowiązuje regulamin serwisu FCBarca.com, który znajdziecie
tutaj.
Online: 1692 Culés
3
@Redakcja
Tak mi coś przyszło z "wieczora" do głowy, trochę w związku z ostatnią ZP.
Może w tej beleczce powiadomień, tam gdzie są ikony nazwy użytkownika, przegląd newsów, wiadomości itd, dałoby się "dostawić" jeszcze jedną ikonkę powiadomień, o postach użytkowników "obserwowanych".
Niech by także, tam wylądowali użytkownicy, którzy zajęli 3 pierwsze miejsca w ZP. Człowiek by ich twórczość trochę poznał, nawet jak na La Ramble regularnie nie zagląda. (może nie być tych, których ma się w "ignorowanych ;)
Jeśli to za dużo, to może przy obserwowanych, mógłby się pojawić "dzwoneczek" jak w YT, albo twitterze, by tego danego użytkownika powiadomienia włączać.
W powiadomieniach o newsach za to, przydało by się, żeby może newsy które zostały otwarte kliknięciem, znikały z nieprzeczytanych. Ja często otwieram sobie kolejne newsy w kartach, a póxniej muszę wracać, oznaczać jako przeczytane.
Mógłby także, w użytkownikach obserwowanych/ignorowanych pojawić się mały licznik dni od ostatniego komentarza (komentarza/artykułu w przypadku redaktora). Upraszczałoby utrzymanie porządku, jak konto ma się od lat i trochę poklikanych.
Wiem, że mało skryptowania to nie jest i rusza się zapewne zakurzone rewiry kodu, ale jak by się udało, o ile oczywiście wartościowe wskazówki.
0
@AxelF Jeśli chodzi o automatyczne odhaczanie newsa to na 100% tego nie będzie bo wiele osób już od dawien dawna o to prosi i Robertinho wyjaśniał że szkoda miejsca w bazie danych/za duży koszt który stale by rósł. Co do innych rzeczy to też bym się nie spodziewał czegokolwiek szczerze mówiąc w najbliższej przyszłości po tym jak Robertinho już tu nie ma.
1
@don'T.R.I.P.e gdyby tak było, to trochę dziwnie w mechanice swojej rozwiązanie.
Bo "baza" powinna zawierać jedynie ID użytkownika, oraz id artykułów które są nieprzeczytane, a więc nie byłe "kliknięte" z poziomu tego użytkownika.
Kliknięcie, powinno automatycznie z bazy usuwać, powiązanie, więc ją odchudzać.
Wiem, że baza danych nie jest liniowa, i jak usunie się wpis, to nie proporcjonalna ilość miejsca znika. W tym celu trzeba bazy przebudować, ale jednak jakoś się to dzieje - jak sam oznaczysz to znikają, więc ja tu różnicy nie widzę. Nie jestem programistą, zaledwie kiedyś się programowaniem bawiłem, ale przyznaję, trochę nie rozumiem ewentualnego założenia, skoro automatyczne usuwanie wpisów z tablicy, miałoby powodować jej powiększanie.
0
@AxelF Wszystko zależy od tego jak to jest ułożone, podejrzewam że tak że jest tabelka z artykułami i tabelka z danymi użytkownika i sprawdza date ostatniego przeczytania. Gdybyśmy chcieli mieć to o czym mówisz to trzeba by odwrotnie do tego co mówisz - każdy przeczytany artykuł musiałby się pojawić jako wpis w tabelce danego użytkownika a brak wpisu oznaczałby brak przeczytania (co już samo w sobie oznacza bardzo dużo operacji/transakcji). W innym przypadku podczas dodawania artykułu trzeba by dodać wpis (oznaczający nieprzeczytanie) dla każdego użytkownika a więc robić monumentalną transakcje przy każdorazowym nowym artykule co byłoby szaleństwem. I o to się rozchodzi że ilošć artykułów stale rośnie tak samo jak użytkowników i baza danych też by rosła w rozmiarze przy takim rozwiązaniu co najwidoczniej byłoby zbyt wielkim obciążeniem dla tej strony. Dodam jeszcze że w produkcyjnych bazach danych praktycznie nigdy się nic nie usuwa, raczej oznacza się flagi usunięcia.
1
@don'T.R.I.P.e strasznie pogmatwany byłby to sposób.
W praktyce, każdy artykuł ma swoje ID, każdy użytkownika ma swoje ID i baza może mieć kilka relacji - ID nieprzeczytanych przez danego użytkownika artykułów, z jego ID, ale to tylko zgadywanka.
0
@AxelF Wybacz ale nie ma sensu to co Ty piszesz. Każdy artykuł ma swoje ID tak? Ok. Każdy użytkownik ma swoje ID? Ok, I co je łączy? Żeby je coś łączyło to musi być tabela łącząca M:M Użytkownicy:Artykuły. I teraz wpis łączący użytkownika z artykułem można dodać albo podczas dodawania nowego artykułu o jego nieprzeczytaniu tak jak ty sugerujesz (i wtedy trzeba naraz dopisać XXX rzędów (dla każdego użytkownika jaki istnieje) lub wtedy gdy użytkownik przeczyta artykuł tak jak ja sugeruje.
1
@don'T.R.I.P.e nie, musi się "zdarzyć" relacja. Relacyjna baza danych na tym polega.
1. Artykuł |------------ Użytkownik 1
2. Artykuł --------------- |
3 . Artykuł ---------------|
... . |
100.. Artykuł. -----------|
Użytkownik klika na teks, usuwana jest relacja do ID artykułu np. nr 100, wciąż są relacje do artykułów 2 i 1. I tak masz przy każdym użytkowniku relacje do nieprzeczytanych, tylko teraz usuwa je kliknięcie na "oznacz wszystkie jako przeczytane".
Nie rozumiem potrzeb tworzenia tabel.
Nie jestem ekspertem, ale kiedyś robiłem do firmy, bazę danych SQL która wiązała ileś ubrań roboczych w rożnych kategoriach, innych Środów wydawanych pracownikom, z samymi pracownikami. Program sprawdzał i pilnował co się komu należy, z jakiej grupy, czy to dostał, kiedy dostał i kiedy może dostać kolejny raz.
Trzymał też później w prosty sposób na sztuki stany magazynowe.
Trzy tabele były - Środki, Kategorie, Pracownicy. Wszystko. Reszta to były relacje i obliczenia.
Chodziło to na jakimś celeronie, więc musiało być leciutkie, bo teraz smartfon jest ze 1000 razy szybszy. A było pisane w Delphi bo nic ponad podstawy C, a pascala tam mniej więcej miałem opanowanego.
Nie mam absolutnie pojęcia, jak to jest zorganizowane na tej stronie, bo na pewno jest dużo bardziej skomplikowane, ale raczej nie jest dobrą praktyką tworzenie przyrastających tabel, dla każdego artykułu.
0
@AxelF Chyba się nie dogadamy xD Nie rozumiem w jaki sposób chcesz mieć w jednej tabeli relacje pomiędzy wieloma użytkownikami i wieloma artykułami czyli związek Many to Many - bez duplikacji to jest nie możliwe. Chyba że sugerujesz dublowanie jednego artykułu przez liczbe użytkowników a potem usuwanie go gdy to przeczyta. Raczej kiepskie rozwiązanie no i nie naprawia problemu o którym cały czas mówie - skąd ten wpis o nie przeczytaniu ma się pojawić? Musi się pojawić podczas dodania artykułu czyli w takim razie jednocześnie nowa relacja (czyli mówiąc bardziej dokładnie wpis w tabelce posiadający ID artykułu oraz ID użytkownika) tak jak to opisujesz musiałaby zostać dodana dla wszystkich użytkowników - kiepsko. Ja sugeruje nie żeby robić tabelke dla każdego użytkownika tylko że istniałaby tabelka z artykułami, tabelka z użytkownikami oraz tabelka łącząca wielu użytkowników z wieloma artykułami. Użytkownik czytając artykuł dodawałby do tej łączącej tabeli wpis czyli w kolumnie "artykuł ID" dane ID przeczytanego artykułu a w kolumnie "ID użytkownika" swoje ID. Każdy artykuł nie znajdujący się w tej tabeli gdy się ją przefiltruje/odpyta używając klucza ID danego użytkownika uznany byłby za nie przeczytany. Pracuje obecnie w firmie jako programista full stack więc wiem na czym polega SQL i takie rzeczy :p
1
@don'T.R.I.P.e ok, nie jestem ekspertem, nie będę się porywał na tłumaczenie czegoś, co sam ledwie liznąłem.
Ja relację z wieloma przedmiotami, osiągałem przez to, że jednym z pól właściwości użytkownika, była tabela z ID przedmiotów. Tu artykułów nieprzeczytanych.
Teraz kliknięciem "oznacz jako przeczytane" zerujesz wartości tej tabeli, a może dałoby się zerować kliknięciem na artykuł i wtedy skrypt usuwałby ID klikniętego artykułu z tego pola w właściwościach użytkownika.
Jestem świadom, że w moim przypadku, przedmiotów było kilkadziesiąt a użytkowników trochę ponad stu. Zasada jest podobna, choć różnica jest taka, że maksymalna długość tabeli na przedmioty w przypadku użytkownika nie była duża.
Kolejna sprawa - dla mnie to jest relacja jeden do wielu. Użytkownik może mieć od 0 - XXXX nieprzeczytanych artykułów po ID. Relacja jest przetrzymywana po jego stronie, bo nie ważne z punktu widzenia użytkownika, kto jeszcze ma nieprzeczytane artykuły.
Ok, nie istotne w sumie. Programistą nie jestem, więc się wykłócać nie będę bo nie mam podstaw.
0
@AxelF No nie ważne, wesołych świą życze :)
1
@don'T.R.I.P.e wzajemnie :)