Чтобы добавлять сообщения и комментарии, .

@gvard:
gvard

Давно ищу программу-записную книжку, пригодную для создания базы данных музыкальных записей. Задача: сохранение, модификация информации по музыкальной коллекции в целях 1) поддержания актуального состояния и 2) сохранения личных рецензий после прослушивания. 3) без обязательной привязки к конкретному носителю (диску, файлу, торренту). Крайне желательна мобильная версия.

Конкретнее, вид отдельной записи, минимум: 1) автор, 2) название, 3) год, 4) описание,
5) Комментарии/рецензия, 6) набор тегов, 7) картинка (обложка).

Вот нашел сейчас жемчужину (привет, Роскомнадзор), будет новая запись:
1) "Denny Zeitlin/David Friesen"
2) "Concord Duo Series, Vol. 8"
3) 1995
5) David Friesen plays an Acoustic Bass made by N.Guignot, ca. 1795
Recorded: Live at Maybeck Recital Hall in Berkeley, CA. on June 5, 1994
Стандарты: 1. All of You (C.Porter) и 3. The Night Has a Thousand Eyes (B.Bernier-J.Brainin).
Относительно легко и в то же время интеллектуально. Привет, Петруччиани! 5/5.
6) "Jazz, Post-Bop, Piano, Bass"

Есть ли БД специально под музыкальные рецензии? Last.fm и иже с ним не предлагать.
Заметки в evernote идут лесом: эта сволочь регулярно находит конфликты версий и не умеет по факту работать оффлайн.
На правах быстрого решения — может быть пока аналоги evernote типа Wiznote?..

@fillest:
fillest

influxdb.com
If you’ve installed InfluxDB locally, the influx command should be available
f@hvdev:~$ dpkg -l | grep influx
ii influxdb 0.9.1 amd64 Distributed time-series database
f@hvdev:~$ influx
influx: command not found

images5.fanpop.com

Very excited to announce InfluxDB has raised an $8.1M Series A from MayfieldFund 8 дек. 2014 г.
Блеать... Ебучие криворукие goблины.
Ну ладно, ок, у меня уже выработался рефлекс, иду репортить. Зашёл в ишьюс. Полистал. Иии чё-то призадумался, а стоит ли продолжать. Но ведь какие альтернативы, нету ведь ничерта

@fillest:
fillest

патент на time series database
Патентомрази хуже сеошников.
Жаль, подача патентов уже запатентована. Или нет?

В комментах тоже ок:
I remember trolling the linked list patent people 10+ years ago. I sent them an email saying my software made extensive uses of linked lists and it had come to my attention that they had patented them. They sent me to their legal department to arrange an agreement.

@fillest:
fillest

Following a Select Statement Through Postgres Internals

@fillest:
fillest

для которых важнее что монга быстро ставится чем транзакции

@ultr0:
ultr0

Знаете, это всё таки космический монстр, если используется в организации около 15-ти лет.

@netneladno:
netneladno

The Design and Implementation of Modern Column-Oriented Database Systems
db.csail.mit.edu

обзорная статья

@netneladno:
netneladno

рекомендую scholar.harvard.edu
охуенный концепт

@ultr0:
ultr0

Это документы, которые хранятся в базе, которые сами по себе база и представляются в виде базы данных. Представления в виде базы данных. Шаблоны тоже. И эти базы заставляют другие базы принимать их отображение. >°<

@ultr0:
ultr0

У конторы, которая стремиться к централизации накопился зоопарк из трёх разных не связанных БД. А теперь всё связывать.

@provaton:
provaton

Почитываю тут сравнения современных баз данных. В одном из них мудрая мысль изложена — relational databases will always be the best for the stuff that has relations. Внимание вопрос — в какой из серьезных систем бывают базы данных без отношений?

@mahury:
mahury

чем мы занимались в прошлый раз в пути туда — набивали патронами магазины к оружию. такое вот развлечение на моторику.

@mahury:
mahury

pp.vk.me

@mahury:
mahury

150 человек под кормежку в лагерь стражи. как то слегка.

@mahury:
mahury

распечатал три десятка фото с БД. похоже надо искать где еще обработанные кадры. так как некоторые чадры четко обрабатывались и выкладывались. но найти не могу ((

@kSM:
kSM

В итоге плюнул на все это дело, нашел доступ по SSH и делаю бэкап через mysqldump

@kSM:
kSM

Дали сайт на доработку на 11 битриксе. Решил сделать бэкап нативными средствами самого Битрикса. Вот уже 50 минут создается дамп базы, размером уже около 2Гб. Страшно. Главное чтобы он не пригодился. (тьфу тьфу тьфу)

@DespicableMe:
DespicableMe

Народ! Имею вопрос: представим ситуацию, когда есть некая бд, данные в которой обновляются. Но не просто так, а посуточно. И не кем-то, не по событию, а просто по времени.
Вот было сегодня в некой записи 500, к вечеру стало 0, или 124. А завтра, автоматом, опять должно стать 500. Так вот вопрос: можно ли это сделать средствами самой бд, или надо сделать некоторый костыль, который будет обновлять эти данные?

@mahury:
mahury

очередная аватарка нашла своего хозяина.

@mahury:
mahury

сорвать людей из города проехать почти тысячу километров для того что бы пробыть неделю в лесах — это тоже надо иметь талант.

@mahury:
mahury

*портрет Рабочая обстановка

@mahury:
mahury

вроде как суворовская электростанция. в комментариях если получится — будут еще фотки со строяка.

@NEKT:
NEKT

Пообщался с Максом. Он обещал отрубить мне руку.

@mahury:
mahury

повар — "не заваривайте чай в чайнике. так как его потом сложно мыть". угу. больше суток без чая. когда я его заварил — пятилитровый чайник ушел минут за двадцать. плюс ставка весьма радовалась именно моему чаю.

@mahury:
mahury

в догонку по тем событиям — мне весьма не нравится моё горло. нормально хоть как то распеться не смог. то что было — явно фигня. горло себя несколько не очень хорошо чувствует.

@mahury:
mahury

ДэДэ — он хорош. Интересный человек.

@mahury:
mahury

появление @NEKT на БД было относительно внезапным. то есть условно ожидаемым, но с весьма низкой вероятностью

@mahury:
mahury

по пути на БД заехали покушать в местную кафешку на берегу волги. там обитали кошки в немалом количестве и кролики.

@mahury:
mahury

попытка отчета.
1. выезд случился более чем на сутки позже чем я изначально думал.
ну не надо пропадать внезапно на долго.
при чем время прибытия с учетом некоторых поправок — как раз уложилось примерно в предполагаемый диапазон.
2. поездка в ночь туда — на удивление хороша. в отличие от предыдущей поездки и пробок практически не было, и трассу починили, по крайней мере ям "прощай подвеска" не было.

про ход событий будет скорее чуть позже еще пост — когда будет первый проход по фотографиям.
пока — почти 5К фотографий (100 гигабайт)(в предыдущий выезд в москву было в два раза больше, но там всё же больше шли именно съемки, а не просто дежурства и прочее занимающее время, но не дающее возможности фотографировать), множество знакомств.

из прочих событий. меня в одежде таки искупали. пришел на мостки. положил фотоаппарат на них. тут выплывет из воды девушка и утаскивает в воду. прямо в куртке и в ботинках.

из утерянного — две деревянных ложки (одну потерял, другую сломал) (одну жалко, так как где я еще такую найду, так что явно нужен переход на складные ложки, ну или столовый набор какой), куртка и перчатки (потеряны на территории лагеря, перчатки выпали из кармана в другой локации и были принесены на базу. с утра обнаружены не были, хотя и куртка уже умирала, да и перчатки тоже явно нуждались в замене), термуха (оставлена в москве, вроде как найдена, но замена нужна срочно, так что через две недели буду закупаться термухой на все оставшиеся денги).
собственно задача была скорее притащить обратно оба фотоапарата + оптику + термуху + карточки памяти + рюкзак и спальники. остальное — не так важно.

по результатам выезда надо
1. термуху. много. в ней прекрасно. 12 часов на солнышке днем в ней + камуфло + панама — сгорело лицо и кисть. и то лицо вероятно можно было бы спасти. ну кроме носа. приоритетно
2. перчатки.
3. камуфляж. комплект полевой одежды нужен. и прямая замена текущей куртки тоже.
4. открытые тапки. так как в кобрах хоть и хорошо, но на жаре уже достаточно некомфортно. хотелось бы чего то более лекого и более быстросохнущего
5. ножи. "ножик для колбаску порезать" это хорошо, но лучше когда в каждом рюкзаке есть свой нож. плюс на себе. и желательно не один.
6. столовый набор. такой как у Зю или просто несклько складных ложек. складные ложки легче, но набор Зю прелестнее.
7. запасной аккум к фотоаппарату.
8. телефон с гпс/глонасс + вайфай + андроид. весьма желательно еще защиту от воды и ударов (потенциально рунбо х5, но это тот еще кирпич, хочется чего то более маленького типа моторолы дефи или самсунг хковер).
9. рацию. вероятно для работы в диапазоне 400-470 мегагерц. (как было выяснено мой фотоаппарат дает помехи при работе на близкорасположенные рации). естественно необходима водозащита.
10. потенциально — еще карточки памяти.
11. потенциально — новый ноутбук.
12. картридер усб 3.0 с поддержкой SDXC. так как хочется скидывать фотографии со всех карточек быстро и без проблем. у меня уже с одной карточки


оружие нужно покупать. это факт. так что по осени, когда разберусь с долгами — получать разрешение и покупать оружие.
необходимость получать права — уже видна, но пока откладываема весьма на долго. года через два.


из того что не получилось — некоторые события над которыми некорые злостно потроллили и еще одно знакомство которое вроде как должно было быть. хотя не понятно чего от последнего знакомства ожидать, но вдруг.

в москве была запланирована по идее еще одна съемка, которая не получилась из за малого времени там + плохой координации. ну и просто некоторые встречи которые могли бы состояться в последний момент. но не состоялись по тем же причинам. в москве как то весьма много сейчас людей обитает. в три-четыре раза больше чем в питере?

опять же чисто съемок которые могли быть в поле — как минимум одна обломалсь из за погоды, и еще одна из за того что уехали на сутки раньше чем думали. собственно уехали в том числе из за погоды.

@mahury:
mahury

Брить Бобра законичлось. музыка и девушки? не, не видел. посты/усиление/сон/отдых. никаких близких отношений. знакомств да, немало. всё же мнение что в хулиганнике половина адекватных людей фестиваля- похоже было весьма правильным. ну да. есть там некоторые злобные тролли. но без них никак. а так да. они хороши.

@mahury:
mahury

косплею зомби. пока получается не очень.

@mahury:
mahury

большой фестиваль — это тогда когда на поле люди приезжают на стройку еще за месяц до событий.

@mahury:
mahury

стоило уезжать за почти тысячу км от дома в лес, что бы продолжать тупить в ноутбук. правда в первый раз за неделю. тут есть Нект, а так же внезапно знакомые с Бельтайна Фил, Скутер, Вилги и некоторые другие. людей тут много разных интересных. "половина адекватных людей на всем фестивале собралась в хулиганнике". при том что хулиганник не такой большой и всего тут порядка пяти тысяч человек собралось по приблизительным оценкам.

@mahury:
mahury

сижу в лесу. обгорел. сплю часов по пять в день. сейчас фоточки досмотрю и наверное дальше на дежурство. уже в минусе две ложки, коробка с чаем и подозреваю что это не последнее что у меня в минус уйдет. ложки весьма жалко. так как кушать мне теперь нечем.

@Tenno-Seremel:
Tenno-Seremel

Гружу ~ 80 метров в удалённую MySQL базу по не особо быстрому интернету, да и сам сервер, походу, не особенно силён. SSH нет, растительности нет, полезных ископаемых нет. Шёл третий час…

@eof404:
eof404

Тута предложили в многопользовательском веб — приложении создавать новую БД для каждого пользователя. Типа и масштабировать легче будя, и в чужие данные никто залесть не сможет... Или может лучше таки по старинке — user_id в каждой табличке хранить?

@eof404:
eof404

Есть ли способ синхронизировать структуру БД (MySQL) между несолькими компами?

@DespicableMe:
DespicableMe

Народ, может поможете? Может кто-то сталкивался с таким?
Суть проблемы такова: когда-то давно (в 2009) некий хакер "восстановил" 700 записей БД. Каким образом он это сделал и сделал ли вообще - не ясно. Кто он и откуда - загадка. Но, с тех пор счётчик записей БД показывает неверные цифры. Они сильно меньше.
Как мне найти различия в структуре данных? Хотя, по идее, всё верно и всё на месте. Уточню, что была БД access, недавно я её перенёс на MS SQL.
Возможно, что различий в структуре нет.
Я уже пробовал найти пустые записи. Но ответ был отрицательным. Их нет.
Я пробовал найти одинаковые записи и в предыдущем своём посте написал запрос. Ответ отрицательный.
Возможно, что он заполнил таблицу случайными данными. Тогда найти их получается никак. Но это едва ли могло сказаться на счётчиках.
Я сейчас посмотрю ещё на запросы, которые использует программа, но едва ли что-то полезное там есть.

@DespicableMe:
DespicableMe

Может я делаю что-то не так? Решил запустить простенький скрипт для поиска одинаковых записей в БД. Может я зря жду? Оно уже работает так минут пять.
SELECT * FROM doc d1
WHERE 1<
(SELECT count(*)
FROM doc d2
WHERE d1.item like d2.item)

@eof404:
eof404

Вот есть у мну несолько очень похожих сущностей, как лучше сделать — каждой сущности создать по отдельной таблице в БД, или хранить все в одной таблице?