Dmitry Roo, решаемые установкой AS постарше и подключением смарта вместо эмулятора.
Но вы взялись додумывать за ТС то, чего он не говорил, да еще и оторвались от реальности.
Посмотрите, какие вопросы задает ТС. Ну какой тут, на хрен, Андроид?
Drno, а ТС где-то написал, что у него гипер-проект, требующий убер-железа?
Судя по наивности вопроса, его задачу - хелловорлды - и это железо на ближайший год кроет, как бык овцу.
Такой формат - это частный случай "красивого" отображения конкретно сотового номера.
В базе номера следует держать без всяких красивостей, иначе их затрахаешься искать, например.
А оформить уже полученный из базы номер "красиво" можно буквально, совершенно в ЧЕМ УГОДНО.
GaalSpear, дык при таком объеме они просто по теории вероятности непременно содержат общие подстроки для небольших N. Даже внутри одной строки.
Надо все-таки искать частности и вычленять, что именно интересует. Иначе в решении перемножаются терабайты на терабайты, и привет суперкомпьютерам.
You can use our public rendezvous/relay server, or self-hosting, or write your own server
AnyDesk в последнее время стал просить денег, а в предпоследнее - не стал, и та предпоследняя (до 6.0.8) версия продолжает работать, ничего не прося ;)
Что это за строки? Если нужно просто найти общие слова - так это делается разбиением и индексацией каждой строки, а потом работой с индексами. Если же вам нужно любое побайтовое совпадение - словари получатся космических масштабов, не вариант.
lexstile, название order_dishes верно отражает отношение один-ко-многим. Может, у вас в модели оно прописано иначе?
Называется это - работа с БД. Eloquent реализует Active Record, в ней удобно тянуться по связям типа ->dishes()->, когда они уже есть. При создании же записей бывает удобнее писать напрямую, без накладываемых этой логикой загибов.
lexstile, вот в этой order_disheS и будут поля order_id да dish_id, и создавать эти записи можно напрямую, без всяких многоступенчатых обращений по зависимостям.
VladChekunov, вы решаете проблему читаемости глазами, добавляя проблему читаемости окружением разработчика. Да еще и добавляете лишнее место, где можно допустить ошибку.
Имхо, ваш "вариант" просто не имеет прав на существование.
Артем Колчин, см. выше. Философия Битрикса на 80% состоит из "исторически сложилось", а на 20% - из "мы так видим". Лепить из этого что-то свое - себе дороже.
Артем Колчин, у БУС пять лицензий, в трех из которых магазин включен.
У вас, видимо, Старт или Стандарт. Ну, делайте велосипеды.
Только делать велосипеды из Битрикса опасно и больно. Уж лучше собственная табличка в БД, четко огражденная от всего остального, чем шаманство с инфоблоками.
Из-за специфики области имена констант имеют большую длину
Скорее - из-за неумения грамотно разделить логику - что должно быть в неймспейсе, что в названии класса, а что действительно в названии константы.
Километровые константы - это реальная проблема, мешающая в работе. Вы же вместо ее решения пытаетесь замести ее под ковер и подпереть костылями.
Но вы взялись додумывать за ТС то, чего он не говорил, да еще и оторвались от реальности.
Посмотрите, какие вопросы задает ТС. Ну какой тут, на хрен, Андроид?