[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Как правильно сравнивать данные
balambasik
Доброго дня.

Есть поле Geo. В нем через запятую записаны коды стран RU, UA, US, BY и так далее. Количество стран не определено. От 1 до 249.

Скрипт определяет код страны юзера. Далее нужно выбрать из таблиц строки где этот код страны есть.

Как правильно выбрать такие строки? Regex, Like ?

И вообще правильно ли хранить так данные. Просто на ум больше ничего не приходит. Не создавать же таблицу с 250-ю полями.


Гость_Миша
Цитата (balambasik @ 5.01.2017 - 15:22)
Далее нужно выбрать из таблиц...

Сколько таких таблиц?
FatCat
Цитата (balambasik @ 5.01.2017 - 14:22)
Не создавать же таблицу с 250-ю полями.

Почему не создавать? Если в таблице будут сотни тысяч строк, поиск Like будет занимать слишком много времени, а селектировать даже по 250 полям будет весьма быстро, если поля проиндексированные.

_____________
Бесплатному сыру в дырки не заглядывают...
balambasik
Опечатался. Таблица одна. И строк в ней не очень много будет. Максимум 500
Гость_Миша
Какое количество стран?
Гость_Миша
Прошу прощения, первый раз не увидел.

Если всего около 250 стран, то нужно сделать отдельную таблицу, как посоветовал FatCat.
kaww
Цитата (balambasik @ 5.01.2017 - 15:22)
Есть поле Geo. В нем через запятую записаны коды стран RU, UA, US, BY и так далее.

В корне неверный подход. Проблему уже сам видишь
Цитата (balambasik @ 5.01.2017 - 15:22)
Regex, Like ?

По этому вбиваешь в гугле "sql нормальная форма" и в итоге на выходе получаешь:
Либо 3 таблицы и связ многие ко многим:
1. tems - эта та, что у тебя уже есть, в которой было поле со списком стран через запятую
2. countries - таблица стран
3. item_countries - таблица связей item_id, country_id
Выборка запросом вида:
select items.*
from countries
inner join item_countries on countries.id=item_countries.country_id
inner join items on item_countries.item_id=item.id
where countries.code = 'RU'

Либо 2 таблицы и связь один ко многим (что не совсем нормальная форма, но может быть оправдано в некоторых случаях):
1. items
2. item_countries
Выборка запросом вида:
select items.*
from item_countries
inner join items on item_countries.item_id=items.id
where item_countries.code = 'RU'
waldicom
Цитата (kaww @ 5.01.2017 - 13:21)
По этому вбиваешь в гугле "sql нормальная форма" и в итоге на выходе получаешь:

все так, но иногда, когда все плохо (или наоборот хорошо), можно и flat table использовать. Денормализации не надо бояться. Хотя такое решение, конечно же, должно быть обдумано и понято.

_____________
Свои мозги еще никто не отменял.
Телепатов нету.
balambasik
Да. Со связями у меня туго. Про нормализацию понятно. В ячейке должно храниться только что то одно. Без перечислений, как у меня, через запятую.


Вот гляньте структуру моей таблицы. Каждая строка это рекламная кампания со своими настройками. Геотаргетинг, таргет по ОС, по браузерам и т.д.

user posted image

Мне непонятно... мне вообще ничего не понятно. Куда мне при создании кампании записывать коды стран, браузеры, ОСи. ?

kaww
Цитата (balambasik @ 5.01.2017 - 22:01)
Мне непонятно...

Заведи справочники (таблицы) для Геотаргетинг, таргет по ОС, по браузерам и т.д. И таблицы связей для справочников и кампаний, в которых и будешь "записывать коды стран, браузеры, ОСи." а точнее их идентификаторы. См. первый вариант в моем посте выше. Такая структура позволит использовать индексы для выборки. Твой же вариант - это полный просмотр таблицы, что не есть хорошо.
sergeiss
balambasik, то, что ты хочешь, можно реализовать в PostgreSQL. Там есть разные типы данных, в данном случае подойдет "массив". Посмотри тему http://phpforum.su/index.php?showtopic=83968, там есть ссылки в самом начале.
Но если тебе дОрог именно Мускуль, то да, используй нормализацию.

_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)

user posted image
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.