Я прочитал это конечно, я не врублюсь=)) Ну в чем смысл параметра? Максимальную длину строки указывает? Дак я пробовал превышать эту длину, и чтение все равно происходит.
Фууух!! Выдохнул, вроде все ок! Может действительно чего удалилось из кеша, а может какой глюк. Просто наследующий день, несколько раз перезашел в Хром - все заработало=)
DevMan подскажите плиз, а как Вы решаете на больших разрешениях проблему с мелкими шрифтами на сайтах, в браузере? Или вам не мелко?=))) Просто по мне даже на 27' и то мелко, на 40% сайтов c2n.me/3pKzqv1 . Можно конечно увеличить шрифт в настройках браузера. Но тут 2-а нюанса. 1) Свои сайты (я о сайтах веб-разработчика) тоже могут отображаться не в оригинале 2) ДАЛЕКО не навсех сайтах шрифт увеличиться.
DevMan , да разрешение 1920x1080, т.к. оказалось мне мелко. (на 21,5 я жил на 1366х768). Как будут деньги возможно задумаюсь о покупке 31-32' с разрешением 2560х1440. Думал что 27' это большой моник, и будешь вертеть головой - однако на практике оказлось все отлично, поэтому может даже 31-32' буду брать
Кстати говоря, что хочу сказать. Когда я только "знакомился с компами", общался с одним довольно заядлым ИТ-шником. Он все хвастался, что у него за 8лет работы с ПК 100% зрение. А секрет мол у меня один - я банально НЕ ставлю высокое разрешение. Вот и я с первым ЭЛТ-монитором года 2,5 вообще сидел на разрешении 800х600, как только выставляешь разрешение выше - чувствуешь что глаза устают быстрее. Но это конечно тоже все ИНДИВИДУАЛЬНО. Кому то это совершенно не подойдет.
DevMan Вообщем, старина, как вы и писали, оказалось что все СЛИШКОМ индивидуально=)) Сначала я в магазине посмотрел моники обоих разрешений (24, 27). Когда я был в магазине мне почему то показалось что 24 прям в жилу, а 27 - крупноват. Но дело в том что я уже ОЧЕНЬ привык к небольшим разрешениям. Напр. на 21,5 дюйма у меня 1360х768, если я ставлю 1920х1080 (или даже 1680х) для меня это сильно мелко, вот мелко хоть убей! Ну подгоняю я шрифты в винде и прогах, но ведь все равно много где иконки и шрифты не меняются. Напр, сайты читать тоже мелко, а гонять туда-сюда масштаб/ либо устанавливать другой шрифт - не буду. Вообщем сначала я купил 24' . Привожу его вчера домой, выставляю 1920х1080, ну блин, по крупнее, но все равно мелко и все тут=))) Вообщем благо магаз не отказались заменить мне моник на 27'. Завтра буду забирать его, и тестить=) Отпишусь об ощущениях.
Вячеслав Овчинников: Выловил - внизу, в панели Шторма вылазиет execute task, нажимаю, открываются таски c2n.me/3o0DlMb . Только где такой таск убрать, который грузит Хром, все перерыл не нашел.
coodan: "А тут ведь так вопрос и стоит - школота SQL освоить не может и что такое нормализация не понимает - еще бы, читать то он ничего не хочет."
=)
"Конечно, речи о том, чтобы походу кроить таблицу не шло."
- Дак об этом и вопрос был. В том, что если это Мегамаркет товаров, то З-А-Р-А-Н-Е-Е ни типы ни атрибуты НЕИЗВЕСТНЫ. Раз типы неизвестны то и поля по которым будет осуществляться поиск/сортировка/сравнения - тем более заранее неизвестны. Не о жесткой структуре речь. (У меня сейчас подобное в скрипте Агентства Недвижимости, но там попроще правда.)
"Другая альтернатива - создавать отдельные таблицы для отдельных категорий и их обрабатывать отдельно. Внутри одной категории структура таблицы очевидна. "
- Ну т.е. создавать таблицу на каждый Тип товара так? И разрывать(разряжать) основную? Дак об этом ТС и пишет
"По поводу noSQL - штука, наверное, мощная"
- Дело не в мощности. Первична РЕАЛЬНАЯ ЗАДАЧА. И здесь задача - это динамичные, изменчивые метаданные. Инструмент - вторичен. Применяются эти вещи взависимости ОТ ЗАДАЧИ. Не по принципу что мощнее/не мощнее=)) Да и степень нормализации зависит от реальных задач и внешних факторов. Не по принципу "как это математически красивее"=))
Когда Э.Кодду этот вопрос задали на его первой презентации РБД он ничего ответить не смог. Это один из ортодоксальных недостатков РБД - проблемы с динамичными метаданными.
coodan: Вообще если, так сказать с "математической" точки зрения, думаю Вы правы, нужна одна большая таблица. Но с практической...
1) Т.к. заранее ни кол-во типов, ни кол-во атрибутов неизвестно - мы каждый раз вмешиваемся в СТРУКТУРУ основной таблицы товаров.
2) Кол-во записей может быть огромным. Alter у таблиц с большим числом записей - это известная неразрешенная толком проблема. Он будет ложить базу МИНИМУМ на несколько часов при КАЖДОМ добавлении нового столбца. И уже задача не выполнена - т.к. изначально она подразумевает довольно динамичное добавление/удаление новых и новых столбцов.
3) В MySQL максимум 4096 столбцов на таблицу, в PostgreSQL 250-1600, в Oracle 1000
4) Если не "разрядить" эту таблицу, она будет ОГРОМНОГО размера. Вряд ли это будет оптимально в плане скорости работы с ней. Последний пункт я ХЗ тут просто мое скромное мнение=)) (Тестов таких не делал)
5)сложнее оперировать типами товаров - как самостоятельными сущностями, т.к. они "размазаны" хаотично по таблице
coodan: Вы тоже странное решение привели=)) Я конечно не спорю, просто почитав тему тоже любопытно. Вот например вы пишите "В самом простом случае этот параметр заслуживает отдельной колонки в общей таблице." Если задача - гипермаркет разнотипных товаров. То таких параметров, по которым проводится поиск может быть несколько тысяч. И как делать таблицу с 5-8000тыс полей?=)) ИМХО в подобной задаче нужен какой-то гибрид с NoSQL. Но это конечно просто ИМХО=))