Браузер, конечно, не должен. Браузер вообще не должен встраивать кодеки. В конце топика написано про gstreamer, который ищет кодеки в системе. А в каком формате файл, это уже должно быть на совести разработчика. Если ты youtube, используй самый распространённый кодек. Если тебе плевать на линуксоидов, используй windows media video.
А почему не всё? Все приложения стремятся в веб, каналы пухнут. Появляются Веб ОС, в которых я могу делать то, что мог делать локально на компьютере… А свой любимый фильм помотреть не могу. Мне его, видите ли, надо перекодировать.
Сейчас, я могу создать онлайн тектовый документ любого формата. Никто не говорит PDF это не для интернета.
А как же тонны медиа файлов в других форматах? Их всё равно придётся перекодировать c помощью H.264 или OGG, как сейчас приходится перегонять видео в flv. Или стандарт нацелен только на youtube и тд?
Очень слабо разбираюсь в кодеках, но когда только заговорили про поддержку кодеков в браузерах, я подумал: вот у меня есть видеоплеер и и он не проигрывает какойто файл, узнаю какой кодек ему нужен, устанавливаю и наслаждаюсь просмотром. Причём, другой видеоплеер тоже найдёт этот установленный кодек. Зачем вшивать кодеки в браузер?
товарищ, я сам тоже из Минска. Недавно ехал из России, где провёл неделю, на машине. Когда въезжал на территорию Беларуси, чуть не прослезился. У нас реально лучше дороги. И по улице не страшно без паспорта ходить.
вообще тупая тенденция у всех браузеров пихать табы сверху. мне на широкофрматном мониторе намного удобнее пихать их слева по вертикали. у меня в этом случае под каждым табом будет по адресной строке или как?
Это всего лишь цитата. Мнение человека о том, какими должны быть деньги. А вы лучше всю трилогию почитайте. Довольно точно, хоть и утрированно, описываются процессы, которые сейчас протекают в мировой экономике.
То миллионные массивы, то 50 записей в таблице.
50 записей в таблице groups. Вы не следите за темой, а опять цепляетесь за возбуждающие вас слова=)
Вы, действительно, кроме страдания никаких чувств не вызываете.
никаких средств для работы с такими данными в стандарте SQL не предусмотрено
БД в данном случае ничто иное как просто хранилище. БД вообще не вкурсе, что я туда записал. Неужели вы пишете запросы на чистом ANSI SQL? И храните в БД только целочисленные данные?
И на предложение хранить данные в файле, всегда отвечаете: в БД это хранить нельзя.
— Едьте на поезде.
— Спасибо. Но я боюсь высоты.
Хранить упакованные до битовых полей данные в БД — это странное.
=))) Это настолько же странно, как хранить в БД email, имя или фамилию. Вротмненоги.
ЗАЧЕМ (а не «что» и «где») хранить в БД непригодные к использованию в других запросах, тяжеломодифицируемые и трудноотлаживаемые данные?
Вы правы, незачем. Хранить данные в БД опасно. Особенно, если кол-во записей в таблице не превысит ста.
В лучшем случае время внесения изменений заметно возрастёт из-за постоянных блокировок. В худшем какие-то изменения будут потеряны.
Да, внесение изменений в базу — это беда. Лучше данные в БД вообще не изменять. Согласен.
Но вот о том, что после вычитывания можно в памяти перевести список идентификаторов функций в битовую маску, с которой потом быстро работать — почему-то не подумали.
Да, я правда не подумал, что можно высчитать миллионный массив, а потом прогнать миллионный цикл и создать битовую маску. Респект.
Может быть, есть другой пример, в котором хранение битовой маски в БД является лучшим решением.
К сожалению, у меня не хватит жизни описать примеры, которые каждый хабраюзер считает лучшим решением. Если вы нашли лучшее применение, пожалуйста. Это буду счастлив, если моя статья хоть чуть-чуть вам помогла. И буду рад, если вы приведёте лучшее решение.
Описанный способ, работы с битовой маской с успехом использую в своих проектах. Хранить битмаску в BLOB полях в таблице, кол-во записей в которой не превисит даже 50, я не считаю злом. Но это не тема моего топика. Кэширование я тоже не считаю злом, но, простите, про кэширование на хабре уже писали.
Ох, тяжело=(
Главной идеей топика не было «Давайте-ка всё упакуем и будем хранить это именно в БД в BLOB, и больше нигде нильзя, только так». Я писал не ГДЕ хранить, а ЧТО хранить. Битовую маску.
Можно по-другому придраться:
— На чём вы это написали?
— На PHP
— Нет, php тормозит. Битовые маски говно. Вот если бы на C++…
Давайте лучше поговорим непосредственно про недостатки и скорость работы непосредственно самой маски и операций над ней.
Не понимаю чего вы хотите добиться этим разговором. Я описал метод упаковки данных. Если вы не видите других проблем, кроме типа BLOB в БД, и ваша БД ну очень тормозит с BLOB, то храните в файлах или прямо в памяти. Надеюсь в вашей операционной системе не тормозят операции чтения/записи файов.
Не нужно вытягивать слова, которые конкретно не касаются топика, а потом искать цензурный ответ.
Сейчас, я могу создать онлайн тектовый документ любого формата. Никто не говорит PDF это не для интернета.
50 записей в таблице groups. Вы не следите за темой, а опять цепляетесь за возбуждающие вас слова=)
Вы, действительно, кроме страдания никаких чувств не вызываете.
никаких средств для работы с такими данными в стандарте SQL не предусмотрено
БД в данном случае ничто иное как просто хранилище. БД вообще не вкурсе, что я туда записал. Неужели вы пишете запросы на чистом ANSI SQL? И храните в БД только целочисленные данные?
И на предложение хранить данные в файле, всегда отвечаете: в БД это хранить нельзя.
— Едьте на поезде.
— Спасибо. Но я боюсь высоты.
Хранить упакованные до битовых полей данные в БД — это странное.
=))) Это настолько же странно, как хранить в БД email, имя или фамилию. Вротмненоги.
Вы правы, незачем. Хранить данные в БД опасно. Особенно, если кол-во записей в таблице не превысит ста.
В лучшем случае время внесения изменений заметно возрастёт из-за постоянных блокировок. В худшем какие-то изменения будут потеряны.
Да, внесение изменений в базу — это беда. Лучше данные в БД вообще не изменять. Согласен.
Но вот о том, что после вычитывания можно в памяти перевести список идентификаторов функций в битовую маску, с которой потом быстро работать — почему-то не подумали.
Да, я правда не подумал, что можно высчитать миллионный массив, а потом прогнать миллионный цикл и создать битовую маску. Респект.
Может быть, есть другой пример, в котором хранение битовой маски в БД является лучшим решением.
К сожалению, у меня не хватит жизни описать примеры, которые каждый хабраюзер считает лучшим решением. Если вы нашли лучшее применение, пожалуйста. Это буду счастлив, если моя статья хоть чуть-чуть вам помогла. И буду рад, если вы приведёте лучшее решение.
Описанный способ, работы с битовой маской с успехом использую в своих проектах. Хранить битмаску в BLOB полях в таблице, кол-во записей в которой не превисит даже 50, я не считаю злом. Но это не тема моего топика. Кэширование я тоже не считаю злом, но, простите, про кэширование на хабре уже писали.
Главной идеей топика не было «Давайте-ка всё упакуем и будем хранить это именно в БД в BLOB, и больше нигде нильзя, только так». Я писал не ГДЕ хранить, а ЧТО хранить. Битовую маску.
Можно по-другому придраться:
— На чём вы это написали?
— На PHP
— Нет, php тормозит. Битовые маски говно. Вот если бы на C++…
Давайте лучше поговорим непосредственно про недостатки и скорость работы непосредственно самой маски и операций над ней.
Не нужно вытягивать слова, которые конкретно не касаются топика, а потом искать цензурный ответ.
Можно в файлах хранить. Храните где и как удобней, это не важно.