W mojej opinii wrzucenie tego tak jak jest, nie jest najlepszym pomysłem. Porozbijałabym to na kilka tabel, pewnie wydzieliłabym dane słownikowe, jak limity kilometrów (kategoria biletu), rodzaj biletu (ulgowy, normalny, etc), typ biletu (miesięczny, ulgowy).
Główna tabela miałaby odwołania do tych tabel i ceny biletów.
Wyobraź sobie, że masz aplikację, w której użytkownik wybiera, że chce sobie kupić normalny bilet miesięczny z miasta A do miasta B.
Załóżmy, że aplikacja sama obliczy ilość km lub pobierze je z dodatkowych źródeł. Będzie mocno nieefektywne bieganie po tej tabeli i parsowanie tekstu "od XX do YY" w poszukiwaniu odpowiedniego przedziału.
Na pewno łatwiej będzie znaleźć ten przedział w tabeli:
CategoryID |
MinKM |
MaxKM |
1 |
0 |
5 |
2 |
6 |
10 |
3 |
11 |
15 |
Podobnie można zrobić słownik z rodzajami biletów |
|
|
TypeID |
Name |
|
---------------- |
---------------- |
|
1 |
Normalny 100% |
|
2 |
Szkolny 49% |
|
3 |
Student 51% |
|
W ten sposób aplikacja znajdzie odpowiednią ketegorię i rodzaj biletu, mając te informacje szybko przeszukasz tabelę z biletami: |
|
|
TicketID |
CategoryID |
TypeID |
---------------- |
---------------- |
---------------- |
1 |
1 |
1 |
2 |
1 |
2 |
Możesz pokombinować, jest tu trochę możliwości :)