Raczkuję w MySQL'u, więc proszę o wyrozumiałość...
Mam dwa pytania.
1. pole ID - auto_increment bardzo dynamicznie jest modyfikowane, mam więc obawę, że szybko osiągnie duże wartości. Jaki typ nadać temu polu lub co innego poradzic?
2. Domyślam się, że query w petli bardzo obciąża pamięć. A potrzebuję usunąć wybrane rekordy z tabeli A oraz powiazne z nimi rekordy z tabeli B.
dzieki za pomoc.
Pełna wersja: auto_increment i DELETE
php Początkujący -> Bazy danych
Cytat
1. pole ID - auto_increment bardzo dynamicznie jest modyfikowane, mam więc obawę, że szybko osiągnie duże wartości. Jaki typ nadać temu polu lub co innego poradzic?
INT lub wyżej, najlepiej UNSIGNED.Cytat
2. Domyślam się, że query w petli bardzo obciąża pamięć. A potrzebuję usunąć wybrane rekordy z tabeli A oraz powiazne z nimi rekordy z tabeli B.
Przetestuj jak bardzo zapytanie obciąża. Pozatym pamiętaj o kauzuli WHERE...
Cytat
INT lub wyżej, najlepiej UNSIGNED.
- tak, ale czy mylę się myśląc, że maksymalna wartość pola INT to 999999999? Czy INT nie ma limitu? A po co UNSIGNED - to chyba liczby dodatnie, więc skoro pierwsza to 1 a następne mogą być tylko wyższe...?
Cytat
Przetestuj jak bardzo zapytanie obciąża. Pozatym pamiętaj o kauzuli WHERE...
- pamiętam o WHERE. Czy w tej sytuacji nalepszym rozwiązaniem jest wyszukanie ID rekorow do usuniecia a potem usuniecie ich kolejno z pierwszej a potem drugiej tabeli? Mogę to przetestować na małej liczbie rekordów, ale chcę wiedzieć co się stanie, gdy rekordów będzie ok. 10 000.
Cytat
Cytat
INT lub wyżej, najlepiej UNSIGNED.
- tak, ale czy mylę się myśląc, że maksymalna wartość pola INT to 999999999? Czy INT nie ma limitu? A po co UNSIGNED - to chyba liczby dodatnie, więc skoro pierwsza to 1 a następne mogą być tylko wyższe...
Int może być także ujemne, a unsigned znaczy że jest zapisywane bez znaku.
Cytat
Int może być także ujemne, a unsigned znaczy że jest zapisywane bez znaku.
tak, ale w auto_increment INT nie moze byc ujemne jesli zaczne od 1 - tak, jak w moim przykladzie
Cytat
- tak, ale czy mylę się myśląc, że maksymalna wartość pola INT to 999999999? Czy INT nie ma limitu?
99......... skad to wziales
Cytat
INT[(M)] [UNSIGNED] [ZEROFILL]
A normal-size integer. The signed range is -2147483648 to 2147483647. The unsigned range is 0 to 4294967295.
A normal-size integer. The signed range is -2147483648 to 2147483647. The unsigned range is 0 to 4294967295.
czyli raczej nie prędko przekroczysz limity... 
Cytat
99......... skad to wziales
- nie wiem, widocznie niedokladnie doczytalem.
Cytat
czyli raczej nie prędko przekroczysz limity...
co nie zmienia faktu, ze kiedys przekroczę.
Może rozwiązaniem byłby reset ID. Ale to ryzykowna sprawa, jeśli ktoś akurat jest w trakcie wypełniania formularza.
zeby przekroczyc w przeciagu roku musialbys miec dodanych ok. 5 883 516 rekordow dziennie 
a przez 2 czy 3 lata to chyba zdazysz przerzucic baze dumpem i pokasowane id ci sie wyrownaja, jesli boisz sie o wielki ruch... 
a przez 2 czy 3 lata to chyba zdazysz przerzucic baze dumpem i pokasowane id ci sie wyrownaja, jesli boisz sie o wielki ruch...
ok. dzieki wszystkim za pomoc. to projekt na zlecenie, wiec za 2 lata bedzie juz po okresie gwarancji :wink:
http://www.mysql.com/doc/en/Column_types.html
Cytat
BIGINT[(M)] [UNSIGNED] [ZEROFILL]
A large integer. The signed range is -9223372036854775808 to 9223372036854775807. The unsigned range is 0 to 18446744073709551615. Some things you should be aware of with respect to BIGINT columns:
All arithmetic is done using signed BIGINT or DOUBLE values, so you shouldn't use unsigned big integers larger than 9223372036854775807 (63 bits) except with bit functions! If you do that, some of the last digits in the result may be wrong because of rounding errors when converting the BIGINT to a DOUBLE. MySQL 4.0 can handle BIGINT in the following cases:
Use integers to store big unsigned values in a BIGINT column.
In MIN(big_int_column) and MAX(big_int_column).
When using operators (+, -, *, etc.) where both operands are integers.
You can always store an exact integer value in a BIGINT column by storing it as a string. In this case, MySQL will perform a string-to-number conversion that involves no intermediate double representation.
`-', `+', and `*' will use BIGINT arithmetic when both arguments are integer values! This means that if you multiply two big integers (or results from functions that return integers) you may get unexpected results when the result is larger than 9223372036854775807.
A large integer. The signed range is -9223372036854775808 to 9223372036854775807. The unsigned range is 0 to 18446744073709551615. Some things you should be aware of with respect to BIGINT columns:
All arithmetic is done using signed BIGINT or DOUBLE values, so you shouldn't use unsigned big integers larger than 9223372036854775807 (63 bits) except with bit functions! If you do that, some of the last digits in the result may be wrong because of rounding errors when converting the BIGINT to a DOUBLE. MySQL 4.0 can handle BIGINT in the following cases:
Use integers to store big unsigned values in a BIGINT column.
In MIN(big_int_column) and MAX(big_int_column).
When using operators (+, -, *, etc.) where both operands are integers.
You can always store an exact integer value in a BIGINT column by storing it as a string. In this case, MySQL will perform a string-to-number conversion that involves no intermediate double representation.
`-', `+', and `*' will use BIGINT arithmetic when both arguments are integer values! This means that if you multiply two big integers (or results from functions that return integers) you may get unexpected results when the result is larger than 9223372036854775807.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.